حساب الأرباح والخسائر بدقة في Polymarket: لماذا قد تكون أرباحك وخسائرك غير صحيحة؟

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

مؤلف النص الأصلي:律动BlockBeats

مصدر النص الأصلي:

إعادة النشر: مارس فاينانس

لقد قضيت نصف سنة في تطوير تداول آلي ذاتي في 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) في Polymarket يمكن أن يطابق عدة أوامر maker في معاملة واحدة على السلسلة، وسجلات txHash نفسها تمثل عمليات تنفيذ حقيقية مستقلة.

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

بعد حساب 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: شراء رموز مقابل USDC (مصروف)

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

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

· SPLIT: إصدار USDC مقابل رموز (مصروف)

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

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

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

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

استدعاء GET /activity?user=&limit=500، واستخدام end للتمرير، ثم جمع النتائج حسب النوع.

· قيمة المركز السوقية:

استدعاء GET /positions?user=، وضرب الحجم في السعر الحالي.

· التحقق المتقاطع:

مقارنة النتائج مع API الترتيب الخاص بـ Polymarket (lb-api.polymarket.com/profit?window=all&address=X)، وإذا كانت الفروقات أقل من 10 دولارات، تعتبر صحيحة. الفروقات تعود إلى تقلبات قيمة المركز في الوقت الحقيقي.

اختبار: الترتيب لأعلى 15 عنوان

بعد حساب PnL باستخدام طريقة التدفقات النقدية، قمت بمقارنته مع API الترتيب:

swisstony: +$5,601,000 من التدفقات النقدية، +$5,601,000 من API، الفرق < $10

kch123: +$11,396,000 من التدفقات النقدية، +$11,396,000 من API، الفرق < $10

gmanas: +$5,024,000 من التدفقات النقدية، +$5,024,000 من API، الفرق < $10

الفروق بين الثلاثة عناوين أقل من 10 دولارات، وتعود إلى تقلبات قيمة المركز في الوقت الحقيقي.

بعد أن تأكدت من صحة الطريقة، استخدمتها لتحليل مئات العناوين الكبرى، وكانت نتائجها دقيقة جدًا.

ملخص

مجموع cashPnl من /positions → غير كافٍ، لا يشمل الأرباح المُسواة، وقد يعكس إشارة معكوسة.

مجموع حقل makerPnl → غير كافٍ، غير متوافق مع التدفقات النقدية على السلسلة.

التمييز بواسطة txHash فقط → غير صحيح، لأنه يزيل عمليات تنفيذ حقيقية.

التمرير باستخدام offset + الجمع → غير كافٍ، البيانات مقطوعة، وإذا تجاوزت 3000، يحدث خطأ.

طريقة Data API للتدفقات النقدية → الأكثر موثوقية حاليًا، ودقة أقل من 10 دولارات.

الخطوة الأولى في التداول الكمي ليست البحث عن alpha، بل التأكد من أن حساباتك صحيحة.

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