أوامر السيولة من نوع دعم الانتشار (SS) تُعد من بين أقوى الميزات في ADAMANT Market-Making Bot، لكنها أيضًا الأكثر حساسية. فهي تحافظ على اتساع الضيق والكتب الصحية، لكن منطق إعادة التعبئة البسيط يمكن أن يصبح عُرضة للاستغلال: حلقات إعادة التعبئة تعيد إنشاء التعرض، والظروف المتقلبة تشوه وضع الأوامر، والتحركات أحادية الاتجاه تحوّل آلية مفيدة إلى مصدر لخطر يمكن تجنبه.
يُعالج هذا التحديث الأمر من خلال ترقية من ثلاث مراحل: أداة محاكاة مخصصة، وفصل دعم الانتشار والسيولة الآمنة إلى وحدات فرعية اختيارية، واستبدال منطق إعادة التعبئة القديم القابل للتكرار باستراتيجية مرآة محدودة تحافظ على الانتشار الضيق دون فتح حلقات خسارة غير محدودة.
لماذا تُعد هذه الترقية مهمة
يجب أن يتصرف منطق السيولة بشكل يمكن التنبؤ به تحت الضغط. على عكس سيولة العمق، التي تحترم بشكل طبيعي متوسط أسعار الشراء والبيع، فإن أوامر دعم الانتشار (SS) توجد لدعم الانتشار نفسه. مما يجعلها حساسة للإغلاقات العدائية، والتحركات الاتجاهية المفاجئة، وقواعد الوضع التي تعمل في الظروف الهادئة لكنها تنهار في الظروف المتقلبة. يركّز هذا الإصدار على الحفاظ على فائدة دعم الانتشار دون السماح له بأن يصبح مصدرًا مفتوحًا للخطر.
المرحلة 1: أداة المحاكاة والتصور
قبل تغيير المنطق الأساسي، تم بناء أداة منفصلة لفحص سلوك دعم الانتشار (SS) في بيئة خاضعة للرقابة. تتكون الأداة من trade/tests/liquidity_test.js وtrade/tests/liquidity_test.html، وتعمل كتطبيق Express + Socket.io.
في وضع الورق (paper mode)، تحتفظ الأداة بنسخة واحدة من دفتر الأوامر في الذاكرة. يمكن تشغيل تكرارات دعم الانتشار يدويًا، والنقر على مستوى سعر معين يحاكي الإغلاق الكامل لجميع الأوامر حتى ذلك المستوى، مما يسهل إعادة إنتاج الحالات الحدية وفحص ردود الفعل.
في وضع التشغيل الفعلي (live mode)، تقوم الأداة بتحديث دفتر الأوامر باستمرار من البورصة وتعمل مع السجلات الفعلية ordersDb. لا تزال التكرارات تُشغّل يدويًا، لكن البيئة تعكس الظروف السوقية الفعلية.
تتضمن الواجهة HTML جدول دفتر أوامر ملوّن يميّز بين الأوامر الخارجية، وسيولة العمق، وأوامر دعم الانتشار (SS)، وأوامر المرآة. ويشمل لوحة الإحصائيات عدد أوامر دعم الانتشار المفتوحة، والمغلقة، والملغاة لكل جانب، وقيم VWAP للشراء والبيع، والتغيرات لكل تكرار. كما تتضمن لوحة tradeParams للقراءة فقط الحالة التشغيلية النشطة، بينما تتيح عناصر التحكم اليدوية للمشغلين تشغيل تكرارات دعم الانتشار، وفحص التغيرات في الحالة، ونسخ قيم الخلايا. كل تكرار يُبرز ما تغير، مما يحوّل سلوك السيولة من شيء يتم استنتاجه من السجلات إلى شيء يمكن ملاحظته مباشرة.
المرحلة 2: فصل السيولة الآمنة ودعم الانتشار إلى وحدات فرعية اختيارية
في السابق، كان الحالة الأساسية للسيولة الآمنة ومنطق وضع دعم الانتشار (SS) موجودين داخل mm_liquidity_provider، مما يربط ارتباطًا وثيقًا بين مخاوف مختلفة. يفصل هذا الإصدار بينهما إلى وحدتين مخصصتين: trade/mm_liquidity_safe.js وtrade/mm_liquidity_ss.js.
تُضمّن وحدة السيولة الآمنة الحالة liqLimits وجميع الوظائف المساعدة المتعلقة بها (updateLiqLimits، loadLiqLimits، storeLiqLimits، resetLiqLimits، getLiqLimits، getVwapRangeString). وهي تعالج فقط إغلاقات العمق باستخدام عامل تصفية صارم subPurpose === 'depth'، مما يبقيها مركزة على سجل تنفيذ العمق والحدود المستمدة منه.
تُضمّن وحدة دعم الانتشار (SS) السلوك الخاص بـ SS، بما في ذلك updateSsLiquidity(liquidityOrders, orderBookInfo)، وupdateSsVwap()، ومنطق سعر SS، وحدود عدد أوامر SS، ومنطق وضع المرآة. كما تم نقل الثوابت مثل الحد الأدنى والحد الأقصى لأوامر SS لكل جانب إلى هنا أيضًا.
الملف الرئيسي mm_liquidity_provider.js الآن يحمّل الوحدتين من خلال utils.softRequire(). هذه الوحدات اختيارية: إذا كانت إحداهما مفقودة، لا يزال البوت يعمل بشكل صحيح. تستمر سيولة العمق في العمل. إذا كانت mm_liquidity_safe مفقودة، تكون حدود السيولة الآمنة ببساطة غير نشطة. وإذا كانت mm_liquidity_ss مفقودة، يكون دعم الانتشار غير نشط. لا توجد أعطال، ولا تدفق معطّب، ولا حاجة إلى فروع كود منفصلة.
كما يفوّض المزود قواعد الإغلاق الخاصة بـ SS إلى وحدة SS عند توفرها، ويستبدل حلقة وضع SS الداخلية بـ ss.updateSsLiquidity()، ويُحدّث دفتر الأوامر بعد وضع SS بحيث يمكن لأوامر العمق استخدام منتصف حالي، مما يحسّن اتساق الوضع.
المرحلة 3: استبدال حلقات إعادة التعبئة باستراتيجية مرآة محدودة
هذا هو التغيير السلوكي الأساسي. كان النمط القديم لإعادة التعبئة القابل للتكرار يمكن أن يعيد إنشاء التعرض بطرق غير مرغوبة في بعض سيناريوهات الإغلاق.
القاعدة الأساسية للمرآة
عندما يتم إغلاق أمر SS عادي، يضع البوت أمر مرآة على الجانب المقابل عند السعر المنعكس وبنفس الحجم. لا يضع أمر بديل على نفس الجانب.
بدلًا من إعادة التعبئة بلا نهاية حيث تم استهلاك السيولة للتو، يقر النظام بالإغلاق ويجيب بمقابل محدود عبر الانتشار. هذا يبقي السوق أكثر ضيقًا دون إنشاء حلقة تغذية راجعة غير محدودة لإعادة التعبئة على نفس الجانب.
خصائص أمر المرآة
يتم تمييز أوامر المرآة بشكل صريح بـ subType: 'mirrored'، وsubTypeString: ' (ss mirrored)'، وpriceCorrected: true. يسمح الحقل priceCorrected للمنطق الحالي closeLiquidityOrders بتجاهل أوامر المرآة الصالحة حتى عندما تكون خارج نافذة انتشار SS العادية، بحيث تبقى أوامر المرآة كما هي حيث يجب دون الحاجة إلى مسار إلغاء منفصل.
منع التسلسل (Cascade prevention)
أحد المخاطر الكبيرة في منطق المرآة هو السلوك التكراري: يتم إغلاق أمر مرآة، ثم يُعاد تمثيله مرة أخرى، وهكذا. يتم منع هذا بشكل صريح. لا يتم تمثيل أوامر المرآة المغلقة مرة أخرى. تتحقق الوحدة من subType، وعندما يتم إنشاء مرآة، يتم وضع علامة على الأمر الأصلي كمصدر للمرآة، مما يمنع سلاسل التسلسل ويحافظ على آلية محدودة.
ضوابط المخاطر
حد مسافة المرآة. إذا كان السعر “الحقيقي” للمرآة رياضيًا بعيدًا جدًا عن المنتصف، يعود البوت إلى سعر محدود بالقرب من حافة انتشار SS بدلًا من وضعه هناك بشكل أعمى. هذا يمنع أوامر المرآة من الانفصال عن سلوك السيولة المفيد.
حاجز صلة VWAP. يحافظ دعم الانتشار (SS) الآن على إحصائياته الخاصة للإغلاقات من خلال fillsEngine دورة زمنية مفتاحها subPurpose: 'ss'، ويُتبع buyVWAP وsellVWAP بشكل منفصل عن سيولة العمق. إذا انحرف VWAP الخاص بـ SS أكثر من 2% عن المنتصف الحالي، يُعامل على أنه قديم ويُتجاهل في قيود الوضع. هذا مهم بعد الانعكاسات الاتجاهية القوية، حيث يمكن أن يُحبس منطق SS على جانب واحد من السوق بسبب مرساة VWAP قديمة.
تخفيف الانتشار الواسع. في الأسواق المتقلبة، قد يصبح الانتشار الخارجي مؤقتًا أوسع بكثير من منطقة SS المقصودة. عندما يحدث ذلك بعامل مضاعفة محدد، تُخفّف فحوصات احتلال المرآة بحيث يمكن لدعم الانتشار الاستمرار في العمل بدلًا من التجمد بسبب افتراضات وضع صارمة لم تعد مناسبة للسوق.
وضع SS العادي الجديد المحدود. يحترم وضع SS العادي الآن VWAP الخاص بـ SS عند الاقتضاء. تُوضع عمليات الشراء العادية الجديدة تحت buyVWAP الخاص بـ SS، وعمليات البيع العادية الجديدة فوق sellVWAP الخاص بـ SS، مما يقلل من احتمالية إضافة تعرض جديد بشكل متكرر عند مستويات متزايدة سوءًا.
تحسينات قابلية المراقبة والتحكم من قبل المشغل
أصبح أمر /stats الآن يتحقق من أزواج التداول عبر parseCommandParams، ويقبل أي زوج أو عقد دائم (perpetual ticker) (ليس فقط الافتراضي)، ويشكّل قيم الانتشار لـ 24 ساعة بخط عريض، ويستخدم دقة ثابتة لـ volumeInCoin2، ويعرض حجم التداول وإحصائيات الأوامر المنفذة فقط للزوج الافتراضي، ويشمل أوامر السلم (ld) في إحصائيات الأوامر المنفذة، ويضيف قسم الملاحظات.
تتوفر الآن عرض إحصائيات سيولة غنية من خلال /orders liq full. يتضمن كتلة سيولة العمق مع الحالة، ومعايير الانتشار، وعدد الأوامر، والمبالغ المفتوحة، وحدود السيولة الآمنة، وتاريخ الإغلاقات؛ وكتلة دعم الانتشار مع نطاق انتشار SS، وحدود حجم الأوامر، وعدد الأوامر العادية والمنعكسة، وإحصائيات إغلاق SS، وVWAP، وPnL MTM؛ وكتلة إجمالي مدمجة تجمع بيانات إغلاق العمق وSS؛ ووقت بدء دورة السيولة الحالية؛ ومعلومات الحد الأدنى للطلب في البورصة؛ ومعلومات دفتر الأوامر الحالي عبر وظائف مساعدة قابلة لإعادة الاستخدام لعمق السوق. تستخدم جداول إحصائيات الإغلاق تخطيطًا مضغوطًا من أربع أعمدة: التسمية، والشراء، والبيع، والتغير.
يعرض الآن قائمة /orders liq العادية النسبة المئوية للمعبأة للأوامر المعبأة جزئيًا، وتشمل تسميات subPurpose وsubType مثل ss, mirrored. يحتوي أمر /orderbook على عمود جديد الغرض يُظهر الوحدات النمطية للبوت التي تتوافق مع كل مستوى سعر، مستمدة من السجلات الحية ordersDb.
أصبح أمر /enable liq الآن يتضمن خطوة تأكيد قبل تغيير معايير السيولة، ويتحقق من قدرات البناء: يتم رفض ترميز نطاق العمق إذا كانت mm_liquidity_safe مفقودة، وتُرفض معايير SS إذا كانت mm_liquidity_ss مفقودة، مع رسالة واضحة. تم إضافة أمر فرعي جديد /enable liq reset لإعادة تعيين mm_liquidityInitTs ومسح liqLimits، وإعادة بدء دورة VWAP بعد التأكيد.
تلقّت أوامر /buy و/sell اليدوية تحسينًا في الأمان: إذا انحرف سعر الطلب المطلوب عن السوق بأكثر من 1000%، يتوقف البوت ويطلب التأكيد عبر /y، لحماية من أوامر الأسعار المتطرفة غير المقصودة. أصبح أمر /account الآن يتعامل مع قوائم الرسوم الفارغة من واجهات برمجة تطبيقات البورصات بشكل أكثر سلاسة.
لا تغييرات كاسرة
كلا الوحدتين mm_liquidity_safe وmm_liquidity_ss اختياريتان. إذا كانت إحداهما مفقودة، يستمر mm_liquidity_provider في العمل بشكل صحيح مع تفعيل سيولة العمق. التطور الوحيد على مستوى التنسيق هو أن مفاتيح إحصائيات fillsEngine قد تتضمن الآن جزءًا اختياريًا :<subPurpose>؛ وتظل السجلات الحالية دون هذا الجزء صالحة وغير متأثرة.
ملخص
تقوم هذه الترقية بثلاثة أشياء. تجعل دعم الانتشار مرئيًا من خلال أداة محاكاة تحوّل سلوك السيولة الخفي إلى شيء يمكن فحصه وإعادة تشغيله. تجعل دعم الانتشار وحداتيًا من خلال فصل السيولة الآمنة وSS عن مسار مزود واحد. والأهم من ذلك، تجعل دعم الانتشار أكثر أمانًا من خلال استبدال نموذج إعادة التعبئة القابل للتكرار باستراتيجية مرآة محدودة مصممة للحفاظ على الانتشار الضيق دون تمكين حلقات خسارة جامحة.
بالنسبة لأنظمة صناعة السوق، هذا هو الاتجاه الصحيح: ليس المزيد من النشاط لمجرد النشاط، بل سلوكًا أكثر ذكاءً تحت الضغط السوقي الفعلي. أصبح دعم الانتشار الآن أكثر وضوحًا، وأسهل في الصيانة، وأكثر صعوبة بكثير في الاستغلال.