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

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

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

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

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

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

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

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

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

kch123: مجموع cashPnl -$3.52 مليون، الترتيب الفعلي +$11.4 مليون، الإشارة معكوسة

gmanas: مجموع cashPnl -$2.64 مليون، الترتيب الفعلي +$5.02 مليون، الإشارة معكوسة

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

اختبرت الثلاثة عناوين أعلاه: استدعاء GET /activity?offset=3100 يعيد خطأ HTTP 400، مع رسالة max historical activity offset of 3000 exceeded. المستخدمون النشطون لديهم آلاف المعاملات، و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=