مطور يشارك كيف يبني روبوت تداول Polymarket، من خلال التقاط تقلبات الأسعار في سوق BTC لمدة 15 دقيقة، وتحويل 1,000 دولار إلى 1,869 دولار خلال أيام، مع عائد استثمار بنسبة 86%. المقال يشرح بالتفصيل منطق بناء الروبوت، طرق الاختبار، وقيوده.
(مقدمة سابقة: سوق التنبؤ الرائد Polymarket أعلن عن بناء L2 خاص به، هل انتهت ورقة Polygon الرائدة؟)
(معلومات إضافية: كيف تحقق عائد سنوي بنسبة 40% من خلال استغلال Polymarket؟)

فهرس المقال

• منطق بناء الروبوت
• الاختبار
• قيود الاختبار
• البنية التحتية

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

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

منطق بناء الروبوت

منطق هذا الروبوت يعتمد على استراتيجية قمت بتنفيذها يدويًا سابقًا، ولزيادة الكفاءة حولتها إلى نظام آلي. يعمل الروبوت على سوق “BTC 15 دقيقة UP/DOWN”.

يعمل الروبوت على برنامج مراقبة فوري، يمكنه تلقائيًا التبديل إلى الجولة الحالية من سوق BTC 15 دقيقة، عبر تدفق WebSocket لنقل أفضل سعر شراء / بيع (best bid/ask)، ويعرض واجهة طرفية ثابتة، ويتيح التحكم الكامل عبر أوامر نصية.

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

buy up / buy down : شراء مبلغ معين بالدولار.

buyshares up / buyshares down : شراء كمية محددة من الأسهم، باستخدام أوامر LIMIT (حد السعر) + GTC (سارية المفعول حتى إلغائها) سهلة الاستخدام، وتنفيذها بأفضل سعر بيع (best ask) حاليًا.

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

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

بعد إتمام Leg 1، لن يشتري الروبوت نفس الجانب مرة أخرى. ينتظر “المرحلة الثانية (Leg 2، أي التحوط)”، ويشغلها فقط عندما تتحقق الشروط التالية: leg1EntryPrice + oppositeAsk <= sumTarget.

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

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

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

• shares: حجم المركز للمرحلتين.
• sum: الحد الأقصى للتحوط.
• move (movePct): حد الهبوط (مثلاً 0.15 = 15%).
• windowMin: مدة تنفيذ Leg 1 من بداية كل دورة، بالدقائق.

الاختبار

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

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

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

فكرتي الثانية كانت استخدام بيانات تاريخية من API سوق CLOB الخاص بـ Polymarket للاختبار. للأسف، بالنسبة لسوق ارتفاع/انخفاض BTC لمدة 15 دقيقة، كانت نقطة النهاية لبيانات التاريخ دائمًا فارغة. لا توجد بيانات سعرية سابقة (ticks)، لذلك لا يمكن اختبار “هبوط مفاجئ خلال حوالي 3 ثوانٍ”، وبالتالي لا يمكن تفعيل Leg 1، وأي معلمات ستؤدي إلى دورة واحدة أو عائد استثمار 0%.

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

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

سيسجل المسجل لقطات (snapshots) على القرص، تتضمن:

• الطابع الزمني
• معرف الجولة (round slug)
• الثواني المتبقية
• معرف رموز UP/DOWN
• أفضل سعر بيع (best ask)

ثم، يعيد “اختبار مسجل (recorded backtest)” تشغيل هذه اللقطات، ويطبق نفس المنطق الآلي بشكل حاسم. هذا يضمن الحصول على بيانات عالية التردد اللازمة لاكتشاف حالات الهبوط والتحوط.

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

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

• الرصيد الابتدائي: 1000 دولار
• كل عملية تداول 20 سهم
• sumTarget = 0.95
• حد الهبوط = 15%
• windowMin = 2 دقيقة

كما طبقت رسوم ثابتة بنسبة 0.5% وفارق سعر 2% للحفاظ على سيناريو محافظ.

أظهر الاختبار أن العائد على الاستثمار (ROI) هو 86%، وتحول خلال أيام قليلة من 1000 دولار إلى 1869 دولار.

ثم جربت مجموعة معلمات أكثر حدة:

• الرصيد الابتدائي: 1000 دولار
• كل عملية تداول 20 سهم
• sumTarget = 0.6
• حد الهبوط = 1%
• windowMin = 15 دقيقة

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

هذا يوضح بوضوح أن اختيار المعلمات هو العامل الأهم. يمكن أن يحقق لك أرباحًا هائلة، أو يتسبب في خسائر كبيرة.

قيود الاختبار

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

• أولاً، البيانات المستخدمة كانت لبضعة أيام فقط، وقد لا تكون كافية للحصول على رؤية شاملة للسوق.
• تعتمد على لقطات أفضل سعر البيع (best-ask) المسجلة؛ في الواقع، قد يتم تنفيذ الطلبات جزئيًا أو بسعر مختلف. كما أن عمق دفتر الطلبات وحجم التداول المتاح لم يتم نمذجته.
• لم يتم التقاط تقلبات أقل من ثانية (البيانات مأخوذة كل ثانية). على الرغم من أن الطابع الزمني لكل ثانية موجود، إلا أن الكثير يمكن أن يحدث بين الثواني.
• في الاختبار، تم فرض انزلاق سعر ثابت، ولم يتم محاكاة تأخيرات متغيرة (مثل 200–1500 مللي ثانية) أو ذروة الشبكة.
• كل عملية تداول تعتبر “تنفيذ فوري” (بدون انتظار الطلبات، أو وضع أوامر معلقة).
• الرسوم مفروضة بشكل موحد، بينما في الواقع قد تختلف حسب السوق / الرمز، أو نوع المتداول (مقدم الطلب أو المشتري)، أو مستوى الرسوم أو الشروط.

للحذر، طبقت قاعدة: إذا لم يتم تنفيذ Leg 2 قبل إغلاق السوق، يُعتبر Leg 1 خسارة كلية (total loss).

وهذا محافظ، لكنه لا يعكس دائمًا الواقع:

• أحيانًا يمكن إغلاق Leg 1 مبكرًا،
• أحيانًا يكون في النهاية في المنطقة المالية (ITM) ويحقق ربحًا،
• وأحيانًا يكون الخسارة جزئية وليست كلية.

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

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

• تزعزع دفتر الطلبات،
• تجذب أو تردع متداولين آخرين،
• تؤدي إلى انزلاق سعر غير خطي.

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

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

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

البنية التحتية

أخطط لتشغيل هذا الروبوت على Raspberry Pi، لتجنب استهلاك موارد حاسوبي، ولضمان تشغيله على مدار الساعة طوال أيام الأسبوع.

لكن هناك تحسينات كبيرة يمكن إجراؤها:

• استبدال JavaScript بـ Rust، لتحقيق أداء أعلى ووقت استجابة أقل.
• تشغيل عقدة RPC مخصصة لـ Polygon، لتقليل التأخير بشكل أكبر.
• استضافة على VPS قريب من خوادم Polymarket، لتقليل التأخير بشكل ملحوظ.

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

#####