داخل الشريحة: تكتيكات الأوامر الفرعية بين المجدول والبورصة

مسار Almgren-Chriss يمنحك رقمًا: بِع 4.2 BTC خلال الدقائق الخمس القادمة. جدول VWAP يمنحك نوعًا مماثلًا من الأرقام بمبرر مختلف. لا أحد منهما يقول شيئًا عمّا يحدث بعد ذلك — هل ستصل هذه الـ4.2 BTC إلى الدفتر كأمر واحد قابل للتنفيذ الفوري، أم تنتظر عند أفضل سعر جامعةً رسوم الصانع، أم تختبئ خلف حجم معروض قدره 0.3 BTC، أم يُعاد تسعيرها إحدى عشرة مرة ملاحقةً لعرض سعر متحرك؟ طبقة القرار الثانية تلك هي طبقة التكتيكات، وعلى دفاتر العملات المشفرة التي تهيمن عليها الرسوم، غالبًا ما تحرك هذه الطبقة من الربح والخسارة لكل شريحة أكثر مما يحركه اختيار المجدول الذي يعلوها. تختلف ميزانيات الفواصل الزمنية بين TWAP ونموذج Almgren-Chriss المضبوط جيدًا بمقدار بضع نقاط أساس من الأثر السعري على مستوى الأمر الأصل بأكمله؛ أما دفع رسوم الآخذ على شرائح كان بالإمكان تنفيذها كصانع، أو استنزاف موقع الطابور بإعادة تسعير غير حذرة، فيكلف بهذا القدر في الساعة الواحدة. هذا المقال يتناول الطبقة التي يشغّلها الجميع ولا يوثقها أحد تقريبًا: آلة الحالة التي تحدد كيفية تفاعل كل أمر فرعي مع الدفتر.

طبقتان، واجهة واحدة ضيقة

يُصيغ لوهال ولاروييل في كتابهما Market Microstructure in Practice (الطبعة الثانية، 2018) ما يتفق عليه كل مكتب تنفيذ: طبقة استراتيجية (المجدول) توزّع الكمية عبر الزمن، وطبقة تكتيكية (المتداول الدقيق) تعمل على تنفيذ كل تخصيص مقابل الدفتر الحي. هذا الفصل ليس جماليًا — فالطبقتان تعيشان على ساعات وبيانات مختلفة. المجدول يفكر بالدقائق، ويستهلك توقعات التقلب والحجم، ويحل مسألة تغايرية. أما طبقة التكتيكات فتفكر بالميلي ثانية إلى الثانية، وتستهلك فوارق المستوى الثاني (L2) وتقديرات الطابور، وتحل سلسلة من مسائل التوقف الصغيرة.

يجب أن تكون الواجهة بينهما ضيقة. نزولًا، لكل شريحة $k$:

• الميزانية $q_k$ — الكمية المراد تنفيذها في هذا الفاصل الزمني (وهي $n_k$ في نموذج Almgren-Chriss، أو زيادة منحنى الحجم في VWAP)؛
• النافذة $\tau_k$ — طول الشريحة؛
• الإلحاح — بالنسبة لـAlmgren-Chriss، المرشح الطبيعي هو $\kappa = \sqrt{\lambda\sigma^2/\eta}$، الذي يضغط بالفعل تجنب المخاطرة والتقلب والسيولة في معدل واحد؛ أما في مجدول VWAP فعادة ما يكون مسافة عن نطاق ("نحن متأخرون 1.8% عن منحنى الهدف").

صعودًا: التنفيذات مع الطوابع الزمنية والرسوم، والباقي غير المنفذ، والعجز التنفيذي على مستوى الشريحة مقاسًا مقابل منتصف السعر عند بداية الفاصل. تلك النقطة الأخيرة مهمة: معامل الأثر السعري لدى المجدول $\eta$ يُسعّر بالفعل ما ينبغي أن يكلفه طلب السيولة بمعدل $q_k/\tau_k$. مهمة طبقة التكتيكات بأكملها تتلخص في سطر واحد: تحقيق تنفيذات بتكلفة أفضل من التكلفة التي يمليها $\eta$، دون تسريب وجود الأمر الأصل. إذا كان عجز الشريحة المقاس لديك يتفوق باستمرار على تكلفة النموذج، يمكن خفض $\eta$ المعاير لديك، ويسرّع المجدول، وتتحسن المنظومة بأكملها. وإذا لم تستطع قياس عجز الشريحة بمعزل عن تكلفة الجدولة، فلن تستطيع ضبط أي من الطبقتين — سيكون لديك رقم واحد غامض ومقبضان.

سياسة الباقي جزء من العقد أيضًا. عندما تنتهي الشريحة بكمية غير منفذة، إما أن تُنهي طبقة التكتيكات الأمر قسرًا (تعبر الباقي — الافتراضي تحت إلحاح الموعد النهائي) أو تُعيده إلى المجدول لإعادة التوزيع على الشرائح المتبقية (مقبول في وقت مبكر من جدول ذي $\kappa$ منخفض، لكنه سام قرب الموعد النهائي حيث تتراكم إعادة التوزيع بصمت لتتحول إلى شريحة أخيرة ضخمة).

سلم التصعيد: السلبي أولًا، ثم العدواني بحلول الموعد النهائي

أقدم نتيجة في هذا المجال هي هاريس (1998)، "Optimal dynamic order submission strategies in some stylized trading problems" (Financial Markets, Institutions & Instruments 7(2)): بالنسبة لمتداول سيولة يجب أن ينجز صفقة بحلول موعد نهائي، تكون الاستراتيجية المثلى ديناميكية — الوقوف في الدفتر بأوامر محددة السعر ما دام الوقت رخيصًا، وإعادة التسعير نحو السوق مع اقتراب الموعد النهائي، والعبور في النهاية. كل محرك تكتيكات إنتاجي هو سليل لهذا الشكل: انشر عند أفضل سعر، انتظر حتى تشيخ، صعّد، اعبر. ما تضيفه جداول الرسوم وديناميكيات الطابور الحديثة هو حساب دقيق لتوقيت كل انتقال بالضبط.

نقطة التعادل للعبور

بحساب لكل وحدة، بأسعار نسبية إلى منتصف السعر الحالي، لأمر شراء. العبور الآن يكلف نصف الفارق السعري زائد رسوم الآخذ:

النشر عند سعر الطلب خلال نافذة $\tau$ يُنفَّذ باحتمال $p$؛ التنفيذ يكسب نصف الفارق ويدفع رسوم الصانع $f_m$ (سالبة إذا كانت مكافأة استرداد). عدم التنفيذ يعني العبور في نهاية النافذة بعد أن يكون السعر قد تحرك، في المتوسط، ضدك بمقدار $\delta(\tau) = E[\,\text{الحركة السلبية في منتصف السعر} \mid \text{لا تنفيذ}\,] > 0$ — وهي موجبة بشكل صارم، لأن عدم التنفيذ والانحراف السلبي حدث واحد بذاته: أمر شرائك لا يُنفَّذ عندما يرتفع السوق بعيدًا عنه. تكلفة النشر المتوقعة:

النشر يتفوق على العبور إذا وفقط إذا

حيث $\Pi$ هي الجائزة — العائد الكامل ذهابًا وإيابًا الذي تحققه من الصناعة بدلًا من الأخذ: الفارق السعري زائد فارق الرسوم. هذه هي نقطة التعادل ذاتها التي تحكم اقتصاديات maker-taker الكاملة للتنفيذ، مُختزلة إلى شريحة واحدة.

أرقام، عقد BTCUSDT الدائم: منتصف السعر $100,000، فارق سعري بمقدار تِك واحد s = \0.10$، رسوم من فئة VIP0 تقريبًا صانع 2 نقطة أساس / آخذ 5 نقاط أساس، أي$f_m = $20$،$f_t = $50$لكل BTC. الجائزة$\Pi = 0.10 + 50 - 20 = $30.10 \approx 3$نقاط أساس — لاحظ أن الفارق السعري لا يساهم فعليًا بشيء؛ فعلى أزواج العملات المشفرة الرئيسية ذات الفارق الضيق، الجائزة *هي* فارق الرسوم. لنأخذ تقلبًا يوميًا بنسبة 3$\sigma_{\text{day}} = $3{,}000$) و$\delta(\tau) \approx 0.6,\sigma_{\text{day}}\sqrt{\tau/86400}$ (الرقم 0.6 هو خصم انتقاء سلبي ينبغي معايرته لا الثقة به بشكل أعمى):

• $\tau = 10$ ثانية: \delta \approx \19$، إذن$p^* = 19/49 \approx 0.39$. انشر فقط إذا كنت تتوقع تنفيذًا بنسبة 39% على الأقل خلال 10 ثوانٍ.
• $\tau = 60$ ثانية: \delta \approx \47$، إذن$p^* = 47/77 \approx 0.61$.
• مع مكافأة استرداد للصانع بمقدار نقطة أساس واحدة بدلًا من رسوم بنقطتين (f_m = -\10$):$\Pi = $60.10$، وعتبة الـ10 ثوانٍ تنخفض إلى$p^* \approx 0.24$.

تنبثق من هذا حقيقتان بنيويتان. أولًا، $\delta$ تنمو بمعدل $\sqrt{\tau}$ بينما $\Pi$ ثابتة، لذا $p^\*(\tau) \to 1$: للصبر أجل انتهاء صارم، ومؤقت الشيخوخة ليس قاعدة تجريبية بل نقطة تقاطع منحنيين — تقديرك لـ$p(\tau)$ (مقعر، يتشبع مع نفاد الطابور الذي أمامك) مقابل $p^\*(\tau)$ (متصاعد). ثانيًا، فئة الرسوم التي تتداول ضمنها تحرك السلم فعليًا. ترقية الفئة التي تخفض رسوم الآخذ تجعل تكتيكاتك المثلى أكثر عدوانية — وهو ترابط يكتشفه معظم الناس فقط عندما تتغير إحصائيات تنفيذهم بعد إعادة تصنيف VIP.

كونت وكوكانوف، "Optimal order placement in limit order markets" (Quantitative Finance 17(1)، 2017؛ arXiv 2012)، يجعلان هذا صارمًا في فترة واحدة: تقليل التكلفة المتوقعة لتنفيذ $S$ وحدة مقسمة بين أوامر السوق والأوامر المحددة (عبر منصة واحدة أو عدة منصات)، مع عقوبة على العجز. الحل ذو المنصة الواحدة صريح وله بنية بائع الجرائد (newsvendor): حجم الأمر المحدد الأمثل يُحدَّده توزيع تدفق الطابور الخارج — انشر حجمًا عدوانيًا عندما يكون الطابور الذي أمامك صغيرًا نسبة إلى التدفق الخارج المتوقع، وغطِّ مخاطر الذيل بأوامر السوق. امتدادهما متعدد المنصات يُحل بالتقريب العشوائي وهو اللب الفكري لمنطق التخصيص السلبي في كل موجّه أوامر ذكي. القراءة العملية لمحرك التكتيكات: $p$ في نقطة التعادل أعلاه ليست ثابتة — إنها دالة لموقع الطابور ومعدل استنزافه، ولهذا يجب على طبقة التكتيكات أن تستهلك مُقدِّر موقع الطابور كمُدخل من الدرجة الأولى.

معامل الإلحاح يضغط هذا السلم بأكمله. $\kappa$ مرتفعة من المجدول تعني أن الزمن المميز $\theta = 1/\kappa$ قصير: النوافذ تنكمش، $p^\*$ ترتفع، والمحرك يقفز مباشرة إلى العبور — بشكل صحيح، لأن المجدول قد أعلن بالفعل أن مخاطر المخزون تتفوق على وفورات الرسوم. أما $\kappa$ المنخفضة فتمدد المرحلة السلبية. يجب ألا تعيد طبقة التكتيكات اشتقاق الإلحاح من رؤيتها الخاصة للسوق أبدًا؛ فتلك مهمة المجدول، وتكرارها يخلق وحدتي تحكم متضاربتين.

إعادة التسعير دون حرق موقع طابورك

بمجرد النشر، ينحرف عرض السعر. ملاحقته بسذاجة — إلغاء، إعادة نشر عند أفضل سعر جديد، تكرار — هي الطريقة التي تدمر بها محركات التكتيكات بصمت احتمال التنفيذ ذاته الذي بَرَّر النشر أصلًا. موقع الطابور أصل له قيمة نقدية قابلة للقياس (موعالمي ويوان، 2016، وضعا سعرًا له: مواقع مقدمة الطابور في دفاتر FIFO السائلة تساوي جزءًا معتبرًا من الفارق السعري)، وكل قرار إعادة تسعير هو صفقة: بيع موقع طابورك الحالي، وشراء موقع في مؤخرة مستوى سعري مختلف. الصفقة تستحق التنفيذ فقط عندما تتجاوز قيمة المستوى الجديد قيمة القديم زائد تكاليف الرسائل. وهذا يتطلب معرفة ما يفعله تعديل كل منصة فعليًا بموقعك في الطابور — والإجابة متباينة بشكل هائل.

CME Globex توثق أنظف الدلالات: تقليل كمية الأمر يحتفظ بأولوية الوقت؛ زيادة الكمية أو تغيير السعر يرسلك إلى مؤخرة الطابور. هذا هو النموذج المرجعي — تخفيض الكمية مجاني، وكل شيء آخر إعادة اصطفاف.

Binance للتداول الفوري كانت تاريخيًا تقدم فقط POST /api/v3/order/cancelReplace — عملية تبدو ذرية من إلغاء زائد أمر جديد لكنها غير معاملاتية (transactional) صراحةً. وضعان: STOP_ON_FAILURE (الافتراضي — إذا فشل الإلغاء، لا يوضع أمر جديد) وALLOW_FAILURE (يوضع الأمر الجديد حتى لو فشل الإلغاء — مرحبًا بالتعرض المضاعف العرضي). يمكن أن تنجح العملية جزئيًا، مُشارًا إليها برمز HTTP 409، لذا يجب على نظام إدارة الأوامر لديك تسوية الجزأين بشكل مستقل؛ والأمر الجديد يبدأ دائمًا حياة طابور جديدة. ثم في 2025 أطلقت Binance ميزة Order Amend Keep Priority (PUT /api/v3/order/amend/keepPriority): تقليل الكمية في مكانها، مع الحفاظ على أولوية الوقت، بتكلفة صفرية من حيث عدد الأوامر غير المنفذة. دلالات CME، بعد خمسة عشر عامًا — والنصف الخاص بتخفيض الكمية فقط.

عقود Binance USDT-M الآجلة لديها نقطة نهاية تعديل حقيقية (PUT /fapi/v1/order)، لكن اقرأ التفاصيل الدقيقة: أوامر LIMIT فقط، ويجب إرسال كل من price وquantity معًا، و*"سيُعاد ترتيب الأوامر المُعدَّلة في طابور المطابقة"* — الوثائق لا تعِد بالاحتفاظ بالأولوية حتى في حالات تخفيض الكمية الصرف. عامِل كل تعديل في العقود الآجلة كإعادة تعيين للطابور تُوفِّر عليك رسالة واحدة فقط وتحافظ على معرّف الأمر. حافة حادة واحدة تستحق المعرفة: تعديل أمر GTX (نشر فقط) إلى سعر من شأنه أن يعبر السوق يؤدي إلى إلغاء الأمر، لا رفضه مع الإبقاء عليه — تطبيق تثبيت لا يتحقق من هذا سيُلغي نفسه عرضيًا من الوجود أحيانًا.

OKX تعرض POST /api/v5/trade/amend-order (newPx، newSz، مع cxlOnFail للإلغاء التلقائي عند فشل التعديل). إنها رسالة واحدة، تحافظ على معرّف الأمر، وتؤكَّد بشكل غير متزامن — sCode = 0 تعني "تم قبول الطلب"، والنتيجة الفعلية تصل عبر قناة الأوامر كـamendResult. ما لا تحدده الوثائق العامة بوضوح لافت هو سلوك أولوية الطابور. لا تملأ هذه الفجوة التوثيقية بالتفاؤل. قِسها: انشر أمرين علاميين عند مستوى هادئ، عدّل حجم أحدهما إلى الأسفل، وراقب أيهما يُنفَّذ أولًا عبر بضع مئات من المحاولات. إلى أن تحصل على تلك البيانات، الافتراض المحافظ — أي تغيير في السعر يعيد اصطفافك في كل مكان، وتخفيض الكمية يحافظ على الأولوية فقط حيث يُوثَّق ذلك صراحةً — هو الوحيد الذي يمكن الدفاع عنه.

النتائج السياسية:

1. تخلّف (Hysteresis)، لا ملاحقة لصيقة. أعِد التسعير فقط عندما ينحرف أفضل سعر أكثر من نطاق $b$ تِكات عن سعرك المعلَّق. داخل النطاق، الانحراف مجرد ضوضاء وموقع طابورك يساوي أكثر من تحسّن سعري بمقدار تِك واحد. نطاق بداية معقول هو 1-3 تِكات مُقاسة بالتقلب قصير الأجل؛ والنطاق الصحيح يجعل إعادة التسعير الهامشية محايدة القيمة المتوقعة: $V_{\text{new}} - V_{\text{cur}} = c_{\text{msg}}$، حيث $V$ هي قيمة الطابور على طريقة موعالمي-يوان و$c_{\text{msg}}$ هي سعرك الظلي لحد معدل الرسائل. عمليات التعديل/الإلغاء وإعادة الإدراج تستهلك ميزانية معدل الأوامر على منصتي Binance كلتيهما؛ ومحرك تكتيكات يلاحق كل تِك سيُجيع بقية منظومتك من سعة الرسائل.
2. عدِّل نزولًا، لا تلغِ وتُعِد النشر نزولًا أبدًا. عندما يخفض المجدول ميزانية شريحة أثناء التنفيذ (مجدول POV يرى الحجم يجف، أو إعادة حل Almgren-Chriss بعد تنفيذات جزئية)، استخدم المسار الحافظ للأولوية حيثما وُجد. هذه هي الوجبة المجانية الوحيدة في الطبقة بأكملها.
3. إلحاح غير متماثل في إعادة التسعير. إعادة التسعير نحو السوق (الملاحقة) تعيد تعيين طابورك عند سعر أسوأ — يجب ألا يُطلَق إلا من منطق التصعيد، وفق مؤقته. إعادة التسعير بعيدًا (السوق أتى إليك) هدية — اقبلها فقط عبر النطاق السلبي، لأن مستواك الحالي على وشك التنفيذ على أي حال.

أوامر Iceberg، حجم العرض، وما يُسرّب نيتك

حجم العرض هو القرار الثالث، وهو صفقة ذات وجهين حقيقية، لا زر تخفٍّ مجاني. السجل التجريبي:

• فراي وساندوس ("The Impact of Iceberg Orders in Limit Order Books"، ورقة عمل 2009؛ Quarterly Journal of Finance، 2017)، على بيانات Xetra: أوامر Iceberg شكّلت 9.3% من الحجم المُرسَل و15.9% من الحجم المنفَّذ، وبلغ حجمها 12-20 ضعف حجم الأوامر المحددة العادية — والمفارقة — عندما يكتشف المشاركون الآخرون وجود أمر Iceberg، يستجيبون بأوامر سوق مطابقة. الحجم المخفي، بمجرد استنتاجه، يجذب التدفق: البحث عن السيولة الكامنة يعمل في الاتجاهين.
• بيسمبيندر وبانايديس وفينكاتارامان ("Hidden liquidity: an analysis of order exposure strategies in electronic stock markets"، JFE 94(3)، 2009)، على يورونكست باريس، حيث شكّلت الأوامر المخفية 44% من حجم العينة: الإخفاء يخفض العجز التنفيذي لكنه أيضًا يخفض احتمال التنفيذ الكامل ويطيل زمن الإنجاز. التعرّض يشتري التنفيذات ويدفع ثمنها بالأثر السعري؛ والخيار يُستخدم تمامًا كما تتنبأ النظرية — الأوامر العدوانية تتعرّض لجذب الأطراف المقابلة، والحجم الصبور يختبئ.
• إيسر ومونش ("The navigation of an iceberg"، Finance Research Letters 4(2)، 2007) يعاملان حجم القمة كمسألة تحسين: العرض الأكبر يُنفَّذ أسرع، والعرض الأصغر يُسرِّب أقل، والأمثل داخلي.

الآليات أولًا، لأنها تُقيِّد عملية التحسين: على كل منصة تقريبًا تدعم أوامر Iceberg الأصلية (Binance للتداول الفوري عبر icebergQty، وOKX عبر أوامر خوارزمية Iceberg الخاصة بها)، كل إعادة تعبئة للقمة المرئية تدخل مؤخرة الطابور عند ذلك السعر. لذا فإن أمر Iceberg ليس "أمرًا واحدًا بحجم مخفي" — بل تسلسل من الأوامر الصغيرة، كل منها يدفع الانتظار الكامل في الطابور، تُطلَق تلقائيًا. عند نقطة تعادل الرسوم أعلاه، هذا مهم: $p$ الفعلية لكل قمة هي احتمال التنفيذ من مؤخرة الطابور، لا احتمال موقعك الأصلي. الطوابير العميقة تعاقب القمم الصغيرة مرتين — تنفيذات أبطأ، وانتقاء سلبي أكثر بقدر عدد إعادات التعبئة.

ثم مشكلة الإشارات. طريقة الكشف الخاصة بفراي وساندوس نفسها هي العبرة التحذيرية: كاشفهما التكراري يعتمد على أكثر نمطي كسل تنفيذ شيوعًا — حجم قمة ثابت وطوابع زمنية لإعادة التعبئة مطابقة للطابع الزمني للصفقة المنفَّذة. أي مشارك يُشغّل ذلك الكاشف (وعلى منصات العملات المشفرة، كثيرون يفعلون — بيانات المطابقة الوصفية الخاصة بالبورصة نفسها تجعل الأمر أسهل حتى للتدفق المتشارك الموقع) يعيد بناء حجمك المخفي في حفنة من إعادات التعبئة. نواقل التسريب، مرتبة حسب مدى شيوع مشاهدتي لها في الواقع:

1. أحجام عرض ثابتة أو مستديرة (0.5 BTC، في كل مرة).
2. إعادة تعبئة فورية وحتمية بعد تنفيذ قمة كاملة — بصمة الطابع الزمني المتطابق.
3. مؤقتات تصعيد حتمية: العبور بالضبط بعد 30 ثانية من كل شريحة، فيُظهر الشريط شيئًا أشبه بمترونوم.
4. زمن استجابة إعادة تسعير ونطاق ثابتان — إيقاع تعديلاتك بصمة مميزة تمامًا مثل أحجام أوامرك، وهو موضوع البصمات الرقمية وتحديد هوية المتداول.

تكلفة الاكتشاف ليست افتراضية. فان كيرفل ومنكفيلد ("High-frequency trading around large institutional orders"، Journal of Finance 74(3)، 2019) يُظهران أن متداولي التردد العالي يميلون ابتداءً ضد الأوامر الكبيرة المؤسسية — موفرين السيولة التي تستهلكها تكتيكاتك السلبية — ثم ينقلبون إلى التداول مع الأمر بمجرد أن يكشف استمراره عن معلومة، فيلاحقون الباقي من الخلف ويرفعون تكلفة الأمر الأصل بشكل معتبر. استجابت مؤسساتهم بموازنة الربح المضاربي مقابل مخاطر الاكتشاف. طبقة تكتيكاتك هي بالضبط حيث تُنفَّذ تلك المفاضلة: عشوائيّة حجم العرض (نسبة موحدة من 30-70% من قاعدة مُقاسة بالتقلب تعمل بشكل جيد)، وأرجحة كل مؤقت بنسبة ±20-30%، والسماح أحيانًا لإعادة التعبئة بالانتظار، وعدم السماح أبدًا لأمرين فرعيين بمشاركة نفس الحجم ونفس طور المؤقت ونفس ملف زمن الاستجابة. لا شيء من هذا يكلف جودة تنفيذ قابلة للقياس؛ وكله يرفع أرضية الضوضاء لأي شخص يُكيّف كاشفًا مع تدفقك.

محرك تكتيكات بسيط

الطبقة بأكملها أعلاه تتكثف في آلة حالة صغيرة لكل شريحة: IDLE → POSTED → (حلقة إعادة التسعير) → CROSSING → DONE، مع بوابة نقطة التعادل عند الدخول، ونطاق تخلّف أثناء النشر، وتصعيد عند الموعد النهائي. النسخة أدناه بسيطة عمدًا — لا مُهايئات منصات، لا إدارة Iceberg — لكنها مدفوعة بالأحداث وخالية من الآثار الجانبية، لذا تنزلق مباشرة في محاكي المستوى الرابع الواعي بالطابور من سلّم محاكاة التنفيذ: المحاكي يستدعي on_tick/on_fill، ويفسر الإجراءات كـpost → GTX/نشر فقط، cross → IOC، cancel_replace/amend_down → دلالات المنصة من المصفوفة أعلاه.

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",)]

ثلاثة تحفظات صادقة. p_fill هنا نسبة بديلة مؤقتة — في الإنتاج ينبغي أن تكون النموذج المُعاير حيًا والمُصنَّف إلى مجموعات من مقال محاكاة التنفيذ، لأن بوابة النشر/العبور بأكملها لا تساوي إلا بقدر جودة ذلك التقدير. adverse_frac تُخفي أصعب كمية في المقال ($\delta$ تعتمد على النظام وترتفع بالضبط عندما يكون النشر أكثر إغراءً)؛ قدّرها من نتائج عدم التنفيذ الخاصة بك، مُصنَّفة حسب نظام التقلب. والمحرك أعلاه يعيد التسعير عبر الإلغاء وإعادة الإدراج دون قيد — نسخة واعية بالمنصة ينبغي أن توجّه تغييرات تخفيض الكمية عبر المسار الحافظ للأولوية وتُحمِّل كل إجراء على ميزانية رسائل.

شغّله داخل المحاكي مقابل شريط إعادة تشغيل قبل تصديق أي من المعاملات. التجربة التي تهم: ثبّت المجدول، امسح escalate_frac وreprice_band، وارسم عجز الشريحة مقابل تكلفة النموذج التي يمليها $\eta$. للسطح هضبة — نطاقات واسعة من معاملات شبه مثلى — ومنحدران: التصعيد متأخرًا جدًا (باقي غير منفَّذ يعبر إلى زخم السوق) وإعادة التسعير بحماس مفرط (كل قيمة الطابور مُحترقة). تريد أن تعرف أين منحدراتك قبل أن يجدها الإنتاج نيابة عنك.

ما ينبغي استخلاصه

1. طبقتان، عقد واحد. المجدول يقرر كم ومتى؛ التكتيكات تقرر كيف. الواجهة هي الميزانية والنافذة والإلحاح نزولًا؛ التنفيذات وعجز الشريحة مقابل منتصف السعر عند بداية الفاصل صعودًا. إذا لم تستطع نسبة العجز إلى طبقة معينة، فلن تستطيع ضبط أي منهما.
2. بوابة النشر/العبور حساب رياضي، لا حدس. انشر إذا وفقط إذا $p > \delta/(\Pi + \delta)$ مع $\Pi = s + f_t - f_m$. على دفاتر العملات المشفرة الضيقة، الجائزة هي فارق الرسوم، لذا فئة رسومك تحدد تكتيكاتك — أعِد ضبط السلم بعد كل إعادة تصنيف.
3. مؤقتات الشيخوخة هي نقطة تقاطع منحنيين — احتمال تنفيذ متشبع مقابل انتقاء سلبي ينمو بمعدل $\sqrt{\tau}$ — لا ثوابت فلكلورية.
4. موقع الطابور أصل؛ اعرف دلالات التعديل لكل منصة قبل إنفاقه. CME: تخفيض الكمية يحافظ على الأولوية. Binance للتداول الفوري: cancelReplace يعيد الاصطفاف دائمًا، وميزة amend-keepPriority لعام 2025 تحافظ عليها لتخفيضات الكمية. عقود Binance الآجلة: كل تعديل يعيد الاصطفاف. OKX: غير موثق — قِس، وافترض الأسوأ في الأثناء.
5. أوامر Iceberg سلسلة من أوامر مؤخرة الطابور، والكسولة منها قابلة للقراءة. القمم الثابتة وإعادات التعبئة ذات الطابع الزمني المتطابق توقيع كشف منشور؛ اجعل الأحجام والمؤقتات عشوائية أو تقبّل أن تُلاحَق من الخلف.
6. أرسل آلة الحالة إلى محاكي التنفيذ أولًا. طبقة التكتيكات هي الجزء من المنظومة حيث يتباعد الاختبار الخلفي عن الإنتاج بأشد ما يكون — وهذا بالضبط سبب انتمائها داخل المحاكي، لا إضافتها لاحقًا.

روابط مفيدة

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)

الاستشهاد

@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.}
}