Yield Farming بنسبة 86٪ APY؟ كيفية استخدام البوتات لـ "الكسب أثناء النوم" على Polymarket

العنوان الأصلي: قمت ببناء بوت Polymarket واختبرت إعدادات معلمات متعددة، وإليك النتائج.

المؤلف الأصلي: @the_smart_ape، باحث في العملات الرقمية

الترجمة الأصلية: Bitpush News

قبل بضعة أسابيع، قررت بناء بوت Polymarket الخاص بي. استغرق الأمر مني عدة أسابيع لإكمال النسخة الكاملة.

كنت على استعداد لبذل هذا الجهد لأن هناك بالفعل فجوة في الكفاءة على Polymarket. على الرغم من أن بعض البوتات في السوق تستفيد بالفعل من أوجه القصور هذه، إلا أنها لا تزال غير كافية، والفرص في هذا السوق لا تزال أكبر بكثير من عدد البوتات.

Bot Building Logic

يعتمد منطق البوت على مجموعة من الاستراتيجيات التي نفذتها يدويًا في الماضي، والتي قمت بأتمتتها لتحسين الكفاءة. يعمل البوت في سوق "BTC 15 دقيقة صعود/هبوط".

يقوم البوت بتشغيل برنامج مراقبة في الوقت الفعلي يمكنه التبديل تلقائيًا إلى جولة BTC 15 دقيقة الحالية، وتبسيط أفضل Ask Price من خلال WebSocket، وعرض واجهة مستخدم ثابتة، والسماح بالتحكم الشامل من خلال أوامر نصية.

في الوضع اليدوي، يمكنك وضع الطلبات مباشرة.

buy up <usd> / buy down <usd>: شراء مبلغ محدد بالدولار.

buyshares up <shares> / buyshares down <shares>: شراء كمية دقيقة من الأسهم، باستخدام أمر LIMIT + GTC (Good 'Til Canceled) سهل الاستخدام، يتم تنفيذه بأفضل سعر بيع حالي.

يعمل الوضع التلقائي في حلقة متكررة من مرحلتين.

أولاً، يراقب فقط تحركات الأسعار ضمن windowMin دقيقة في بداية كل جولة. إذا انخفض أي من الجانبين بسرعة كافية (الوصول إلى نسبة انخفاض لا تقل عن movePct في حوالي 3 ثوانٍ)، فإنه يطلق "المرحلة 1"، ويشتري الجانب الذي شهد الانخفاض الحاد.

بعد إكمال المرحلة 1، لن يشتري البوت أبدًا نفس الجانب مرة أخرى. سينتظر "المرحلة الثانية (المرحلة 2، أي التحوط)" ولن يتم تفعيلها إلا إذا تم استيفاء الشرط التالي: leg1EntryPrice + oppositeAsk <= sumTarget.

عند استيفاء هذا الشرط، فإنه يشتري الجانب المقابل. بعد اكتمال المرحلة 2، تنتهي الدورة، ويعود البوت إلى وضع المراقبة، في انتظار إشارة الانهيار المفاجئ التالية باستخدام نفس المعلمات.

إذا كان هناك تغيير في الجولة أثناء الدورة، يتخلى البوت عن الدورة المفتوحة ويعيد التشغيل بنفس الإعدادات في الجولة التالية.

إعدادات المعلمات للوضع التلقائي هي كما يلي: auto on <shares> [sum=0.95] [move=0.15] [windowMin=2]

· shares: حجم المركز للتداول على مرحلتين.

· sum: حد التحوط المسموح به.

· move (movePct): حد الانهيار المفاجئ (على سبيل المثال، 0.15 = 15%).

· windowMin: الوقت من بداية كل جولة للسماح بتنفيذ المرحلة 1.

Backtesting

منطق البوت بسيط: انتظر انهيارًا مفاجئًا عنيفًا، اشترِ الجانب الذي انخفض للتو، ثم انتظر حتى يستقر السعر وتحوط عن طريق شراء الجانب المقابل، مما يضمن أن priceUP + priceDOWN < 1.

لكن هذا المنطق يحتاج إلى اختبار. هل هو فعال حقًا على المدى الطويل؟ والأهم من ذلك، أن البوت يحتوي على العديد من المعلمات (shares، sum، نسبة الحركة، دقائق النافذة، إلخ). أي مجموعة معلمات هي الأمثل وتزيد من الأرباح؟

فكرتي الأولى هي تشغيل البوت مباشرة لمدة أسبوع ومراقبة النتائج. المشكلة هي أن هذا يستغرق وقتًا طويلاً ولا يمكنه اختبار سوى مجموعة واحدة من المعلمات، بينما أحتاج إلى اختبار الكثير.

فكرتي الثانية هي الاختبار العكسي باستخدام البيانات التاريخية عبر الإنترنت من Polymarket CLOB API. لسوء الحظ، بالنسبة لسوق BTC 15 دقيقة صعود/هبوط، تعيد نقطة نهاية البيانات التاريخية باستمرار مجموعات بيانات فارغة. بدون تيكات الأسعار التاريخية، لا يمكن للاختبار العكسي اكتشاف "انهيار مفاجئ لمدة 3 ثوانٍ تقريبًا"، ولا يمكنه تفعيل المرحلة 1، وبغض النظر عن المعلمات المستخدمة، فإنه يؤدي إلى 0 دورة و 0٪ عائد على الاستثمار (ROI).

بعد مزيد من التحقيق، وجدت أن مستخدمين آخرين واجهوا نفس المشكلة عند استرجاع البيانات التاريخية لأسواق معينة. اختبرت أسواقًا أخرى أعادت بالفعل بيانات تاريخية وخلصت إلى أنه بالنسبة لهذا السوق الخاص، لم يتم حفظ البيانات التاريخية ببساطة.

بسبب هذا القيد، فإن الطريقة الموثوقة الوحيدة للاختبار العكسي لهذه الاستراتيجية هي إنشاء مجموعة بيانات تاريخية خاصة بي عن طريق تسجيل أفضل أسعار البيع في الوقت الفعلي أثناء تشغيل البوت.

سيكتب المسجل لقطات على القرص، بما في ذلك ما يلي:

· الطابع الزمني

· Round Slug

· الثواني المتبقية

· معرف توكن الصعود/الهبوط

· أفضل سعر بيع للصعود/الهبوط

بعد ذلك، سيقوم "الاختبار العكسي المسجل" بإعادة تشغيل هذه اللقطات وتطبيق نفس المنطق التلقائي بشكل حتمي. وهذا يضمن القدرة على الحصول على بيانات عالية التردد اللازمة لاكتشاف الانهيارات المفاجئة وظروف التحوط.

على مدى 4 أيام، جمعت ما مجموعه 6 جيجابايت من البيانات. كان بإمكاني تسجيل المزيد، لكنني اعتبرت هذا كافيًا لاختبار مجموعات معلمات مختلفة.

بدأت في اختبار مجموعة المعلمات هذه:

· الرصيد الأولي: 1000 دولار

· 20 سهمًا لكل تداول

· sumTarget = 0.95

· حد الانهيار المفاجئ = 15%

· windowMin = 2 دقيقة

طبقت أيضًا رسومًا ثابتة بنسبة 0.5٪ وانتشارًا بنسبة 2٪ للبقاء في سيناريو متحفظ.

أظهر الاختبار العكسي عائد استثمار بنسبة 86٪، محولًا 1000 دولار إلى 1869 دولارًا في بضعة أيام فقط.

بعد ذلك، اختبرت مجموعة معلمات أكثر عدوانية:

· الرصيد الأولي: 1000 دولار

· 20 سهمًا لكل تداول

· sumTarget = 0.6

· حد الانهيار المفاجئ = 1%

· windowMin = 15 دقيقة

النتيجة: بعد يومين، كان للاستثمار معدل عائد -50٪.

يوضح هذا بوضوح أن اختيار المعلمات هو العامل الأكثر أهمية. يمكن أن يجعلك تجني الكثير من المال أو يؤدي إلى خسائر كبيرة.

Limitations of Backtesting

حتى مع تضمين التكاليف والانتشار، فإن للاختبار العكسي قيوده.

· أولاً، يستخدم فقط بيانات بضعة أيام، والتي قد لا تكون كافية للحصول على منظور سوقي شامل.

· يعتمد على لقطات أفضل سعر بيع مسجلة؛ في الواقع، قد يتم ملء الطلبات جزئيًا أو ملؤها بأسعار مختلفة. بالإضافة إلى ذلك، لا يتم نمذجة عمق دفتر الطلبات والحجم المتاح.

· لا يتم التقاط التقلبات الدقيقة التي تقل عن ثانية (يتم أخذ عينات من البيانات كل ثانية). على الرغم من أن الاختبار العكسي يحتوي على طوابع زمنية على مستوى ثانية واحدة، إلا أن الكثير يمكن أن يحدث بين كل ثانية.

· Slippage ثابت في الاختبار العكسي، دون محاكاة التأخيرات المتغيرة (على سبيل المثال، 200-1500 مللي ثانية) أو ذروة ازدحام الشبكة.

· يُفترض أن كل جزء من التداول يتم تنفيذه "على الفور" (لا يوجد ترتيب في قائمة الانتظار، لا توجد أوامر معلقة).

· يتم فرض التكاليف بشكل موحد، بينما في الواقع، قد تعتمد التكاليف على: السوق/التوكن، الصانع-المتلقي، مستويات الرسوم، أو الظروف.

للحفاظ على نهج متشائم (حذر)، طبقت قاعدة: إذا فشلت المرحلة 2 في التنفيذ قبل إغلاق السوق، تُعتبر المرحلة 1 خسارة كاملة.

على الرغم أنها متحفظة عمدًا، إلا أن هذا لا يتوافق دائمًا مع الواقع:

· في بعض الأحيان يمكن أن تغلق المرحلة 1 مبكرًا،

· في بعض الأحيان ينتهي بها الأمر في الربح (ITM) وتفوز،

· في بعض الأحيان يمكن أن تكون الخسارة جزئية وليست كاملة.

على الرغم من أن الخسارة قد تكون مبالغًا فيها، إلا أن هذا يوفر سيناريو "أسوأ حالة" عملي.

والأهم من ذلك، لا يمكن للاختبار العكسي محاكاة تأثير طلباتك الكبيرة على دفتر الطلبات أو جذب سلوك مفترس من متداولين آخرين. في الواقع، يمكن لطلبك:

· تعطيل دفتر الطلبات،

· جذب أو طرد متداولين آخرين،

· التسبب في انزلاق سعري غير خطي.

يفترض الاختبار العكسي أنك مستخرج سيولة خالص (متلقي سعر) بدون أي تأثير.

أخيرًا، لا يحاكي حدود المعدل، أخطاء API، رفض الطلبات، التوقفات، انتهاء المهلة، إعادة الاتصال، أو المواقف التي يكون فيها البوت مشغولًا ويفوت الإشارات.

يعد الاختبار العكسي ذا قيمة كبيرة لتحديد نطاق جيد من المعلمات، لكنه ليس ضمانًا بنسبة 100٪ لأن بعض تأثيرات العالم الحقيقي لا يمكن نمذجتها.

Infrastructure

أخطط لتشغيل هذا البوت على Raspberry Pi لتجنب استهلاك الموارد على جهازي الرئيسي وإبقائه يعمل على مدار الساعة طوال أيام الأسبوع.

ومع ذلك، لا يزال هناك مجال كبير للتحسين:

· سيؤدي استخدام Rust بدلاً من JavaScript إلى توفير أداء ووقت معالجة أفضل بكثير.

· سيؤدي تشغيل node Polygon RPC مخصصة إلى تقليل زمن الوصول بشكل أكبر.

· سيؤدي النشر على VPS قريب من خادم Polymarket أيضًا إلى تقليل زمن الوصول بشكل كبير.

أنا متأكد من وجود طرق تحسين أخرى لم أكتشفها بعد. حاليًا، أتعلم Rust لأنها أصبحت لغة أساسية في تطوير Web3.

Original Article Link