العنوان الأصلي: «حساب الأرباح والخسائر بدقة في 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 + الأصل، وخسرت 133 دولارًا على الجانب الشرائي. على شبكة Polygon، تبين أن معاملة واحدة تحتوي على عدة أحداث تحويل USDC مستقلة، وكل منها يمثل صفقة حقيقية.

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

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

استخدام offset (الإزاحة) في استدعاء /activity للتصفح؟ إذا تجاوزت 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=