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

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

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

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

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

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

عند التمرير عبر /activity باستخدام offset، إذا تجاوزت 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=