كيف خسرنا 25 ألف دولار بسبب نزوة واجهة برمجة تطبيقات DEX نحن نتداول بكثافة على perp DEX (حامل أعلى 10 نقاط ، أعلى 5 من حيث الحجم). تبين أن نقطة نهاية واجهة برمجة التطبيقات cancel_order () هي.. خاص. يرجع دائما 200 موافق. يمكنك الاتصال ب cancel_order() من خلال: • معرف طلب ساري المفعول (13295238234991) • معرف طلب عميل صالح • معرف طلب غير صالح أو معرف طلب العميل • معرف الطلب الذي تم إلغاؤه بالفعل • معرف طلب منذ 6 أشهر • شطيرة لحم الخنزير •أمك → لا يزال 200 موافق. هذا جيد إذا كنت تعلم أنه يحدث وتبرمج حوله. لم نفعل. المشكلة الفعلية: • من حين لآخر ، يرتفع create_order () RTT إلى 50 مللي ثانية + خلال الأوقات المزدحمة. • كنا نطلق طلبا ، ثم نلغيه عن طريق معرف طلب العميل قبل أن يهبط الطلب بالفعل. • إلغاء إرجاع 200 موافق ، لذلك نفترض أن الطلب ميت ونزيله من كتبنا. • بعد بضع ثوان ، تمتلأ. → يتم اختيارنا مقابل 10-20 نقطة أساس لكل حادث. كيكر؟ تم خلط هذه الحشوات مع الحشوات العادية ، لذلك كان من الصعب اكتشافها. كان لدينا أيضا حلقات خلفية قديمة قيد التشغيل ، لكنها دورية ولم تلتقطها دائما قبل التعبئة. ضبط: • بالنسبة إلى DEX هذا ، فإننا الآن * نطلب * تأكيد إلغاء websocket أو نستمر في إرسال رسائل غير مرغوب فيها إلى الإلغاء حتى يتم استنفاد الحد الأقصى لعمليات إعادة المحاولة. ضرر: • الخسارة المقدرة: 20 ألف دولار - 30 ألف دولار. درس: • كل واجهة برمجة تطبيقات لها مراوغات. عادة ما تكون غير منطقية ، وأحيانا لا تكون مرئية ، وغالبا ما تكون باهظة الثمن. • تحقق دائما من أن النجاح يعني النجاح في الواقع ، ولا تثق في 200.

نعم ، نحن ندير أيضا استراتيجيات آخذ arb في هذا المكان وربما كنا أيضا "نختار أنفسنا". لكنه سباق ضد جميع MM وعتبات الآخذ لدينا ل perps DEXs أعلى بشكل عام ، لذلك غالبا ما نفوتك أو لا نصل إلى عتبة الآخذ قبل المحاولة

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

@0xKeef