العنوان الأصلي: «حساب الأرباح والخسائر بدقة في Polymarket: لماذا قد تكون حساباتك كلها خاطئة»
الكاتب الأصلي: ليو، محلل التشفير

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

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

كم هو الانحراف كبير؟ المستخدم في الترتيب رقم 3، kch123، حسب طريقة خاطئة خسر 3.5 مليون دولار، لكن الربح الفعلي هو 11.4 مليون دولار. ليس فرق نقاط قليلة — بل أن إشارة الربح والخسارة معكوسة تماما.

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

الخطر 1: cashPnl لا يشمل الأرباح والخسائر التي تم تسويتها

الطريقة الأكثر بديهية: استدعاء واجهة /positions، وجمع حقل cashPnl (ربح وخسارة نقدية).

اختبار عملي لثلاثة عناوين من أعلى 15 في الترتيب:

swisstony: مجموع cashPnl +$35,000، الترتيب الفعلي +$5,600,000، الفرق 158 مرة

kch123: مجموع cashPnl -$3,520,000، الترتيب الفعلي +$11,400,000، الإشارة معكوسة

gmanas: مجموع cashPnl -$2,640,000، الترتيب الفعلي +$5,020,000، الإشارة معكوسة

ثلاثة عناوين، إشارة الربح والخسارة في اثنين منها معكوسة مباشرة.

السبب: واجهة /positions ترجع قيمة cashPnl التي لا تشمل الأرباح والخسائر التي تم تسويتها بالفعل. بعد أن يتم استرداد المركز الرابح تلقائيا إلى USDC، يختفي هذا المركز من استجابة API. المتبقي هو المراكز غير المسوية — وغالبا تكون بخسارة مؤقتة.

تظن أنك تحسب كل الأرباح والخسائر، لكنك في الواقع تحسب فقط الجزء غير المسوي.

الخطر 2: حقل makerPnl غير متوافق مع التدفقات النقدية على السلسلة

في بيانات التداول بصيغة JSONL يوجد حقل makerPnl (ربح وخسارة السوق)، اسمه يوحي بأنه لحساب PnL. لا تصدق.

لاحظت في بيانات السوق أن مجموع makerPnl المحسوب يختلف عن نتائج التدفقات النقدية على السلسلة بمقدار كبير. قد يختلف هذا المضاعف حسب السيناريو، لكن الاتجاه واحد: منطق حساب makerPnl لا يتطابق مع التدفقات الفعلية لـ USDC.

مهما كان الانحراف كبيرا، الخلاصة واحدة: لا تستخدم هذا الحقل لحساب PnL.

الخطر 3: لا يمكن الاعتماد على txHash لإزالة التكرار بشكل فردي

هذا عكس الحدس تماما.

عند ظهور عدة سجلات لنفس txHash (مفتاح المعاملة)، رد الفعل الطبيعي هو: بيانات مكررة، قم بإزالتها.

لكن لا تفعل ذلك. في CLOB الخاص بـ PM (دفتر أوامر الحد الأقصى على السلسلة)، يمكن أن يتم التوفيق بين عدة أوامر من نوع maker في معاملة واحدة على السلسلة، وسجلات متعددة تحت نفس txHash هي في الواقع عمليات تنفيذ حقيقية مستقلة.

كنت سابقا أزيل التكرار باستخدام txHash + asset، وخسرت 133 دولارا على جانب الشراء. عند التحقق على شبكة Polygon، تبين أن هناك عدة أحداث تحويل USDC مستقلة ضمن معاملة واحدة، وكل منها يمثل صفقة حقيقية.

الاستنتاج: لا تعتمد على txHash وحده لإزالة التكرار. لحساب PnL، قم بجمع البيانات الأصلية من /activity مباشرة.

الخطر 4: حد أقصى لصفحات التمرير باستخدام offset

عند التمرير عبر /activity باستخدام offset، إذا تجاوزت 3000، ستحصل على خطأ 400. لم تذكر الوثائق ذلك.

تم التحقق من الثلاثة عناوين أعلاه: استدعاء GET /activity?offset=3100 يرجع خطأ HTTP 400، مع رسالة أن الحد الأقصى لعدد الأنشطة التاريخية هو 3000. المستخدمون يملكون عشرات الآلاف من المعاملات، 3000 غير كافٍ.

استخدام معلمة end (وهي الطابع الزمني لآخر سجل في الصفحة السابقة - 1) كعلامة للتمرير لا يوجد له حد أقصى.

الخطر 5: اختلاف معايير حساب PnL في الترتيب

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

في معظم الحالات، يكون الفرق أقل من 10 دولارات (نتيجة تقلبات السوق في قيمة المراكز في الوقت الحقيقي). لكن إذا كان الفرق كبيرا، قد يكون السبب: فترة تجميع البيانات في الترتيب، تأخير تحديث التخزين المؤقت، أو أن المستخدم يربط أكثر من محفظة proxy.

اختبرت، ووجدت أن حساب PnL باستخدام التدفقات النقدية يتطابق بشكل كبير مع نتائج lb-api. إذا كانت نتائجك تختلف كثيرا، تحقق أولا من اكتمال التمرير (الخطر 4)، أو استخدام الحقول الخاطئة (الخطر 1-2).

الطريقة الصحيحة

بعد تجربة طرق مختلفة، تبين أن أكثر الطرق موثوقية هي جمع التدفقات النقدية عبر Data API. لا تستخدم أي حقول محسوبة مسبقا، بل احسب التدفقات من سجلات المعاملات الأصلية مباشرة.

الصيغة:

PnL = مجموع (TRADE حيث side=SELL) + مجموع REDEEM + مجموع MERGE + مجموع MAKER_REBATE + مجموع REWARD - مجموع (TRADE حيث side=BUY) - مجموع SPLIT + قيمة السوق للمركز

· TRADE BUY: شراء token باستخدام USDC (مصروف)

· TRADE SELL: بيع token واسترداد USDC (دخل)

· REDEEM: استرداد USDC من المركز الرابح (دخل)

· SPLIT: تحويل USDC إلى token (مصروف)

· MERGE: دمج token مرة أخرى إلى USDC (دخل)

· MAKER_REBATE: عمولة Maker (دخل)

· REWARD: مكافآت/توزيعات (دخل)

· مصدر البيانات:

استدعاء GET /activity?user=