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

BlockBeatNews
USDC0.01%

العنوان الأصلي: «حساب الأرباح والخسائر بدقة في 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=

&limit=500، مع استخدام end للتمرير، ثم جمع حسب النوع.

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

GET /positions?user=

، الحجم × السعر الحالي.

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

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

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

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

swisstony: +$5.601 مليون من التدفقات النقدية، +$5.601 مليون من API، الفرق أقل من 10 دولارات

kch123: +$11.396 مليون من التدفقات النقدية، +$11.396 مليون من API، الفرق أقل من 10 دولارات

gmanas: +$5.024 مليون من التدفقات النقدية، +$5.024 مليون من API، الفرق أقل من 10 دولارات

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

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

الخلاصة

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

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

حساب بعد إزالة التكرار بناءً على txHash → غير صحيح، يفقد معاملات حقيقية بقيمة 100 دولار أو أكثر.

التمرير باستخدام offset ثم الجمع → غير صحيح، البيانات مقطوعة، وإذا تجاوزت 3000 تظهر أخطاء.

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

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

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

رابط المقال الأصلي

انقر لمعرفة وظائف BlockBeats في التوظيف

مرحبًا بك في المجتمع الرسمي لـ BlockBeats:

قناة التليجرام: https://t.me/theblockbeats

مجموعة التليجرام: https://t.me/BlockBeats_App

حساب تويتر الرسمي: https://twitter.com/BlockBeatsAsia

إخلاء المسؤولية: قد تكون المعلومات الواردة في هذه الصفحة من مصادر خارجية ولا تمثل آراء أو مواقف Gate. المحتوى المعروض في هذه الصفحة هو لأغراض مرجعية فقط ولا يشكّل أي نصيحة مالية أو استثمارية أو قانونية. لا تضمن Gate دقة أو اكتمال المعلومات، ولا تتحمّل أي مسؤولية عن أي خسائر ناتجة عن استخدام هذه المعلومات. تنطوي الاستثمارات في الأصول الافتراضية على مخاطر عالية وتخضع لتقلبات سعرية كبيرة. قد تخسر كامل رأس المال المستثمر. يرجى فهم المخاطر ذات الصلة فهمًا كاملًا واتخاذ قرارات مدروسة بناءً على وضعك المالي وقدرتك على تحمّل المخاطر. للتفاصيل، يرجى الرجوع إلى إخلاء المسؤولية.

مقالات ذات صلة

حساب بمعدل فوز 41% يشتري عقودًا للفوز لمصلحة بايرن ميونخ على Polymarket قبل الدور نصف النهائي لدوري أبطال أوروبا في 7 مايو

وبحسب Odaily Seer، اشترى حساب تبلغ نسبة فوزه التاريخية 41% عقود الفوز لبايرن ميونيخ بقيمة 103,000 دولار على Polymarket في 6 مايو، بسعر دخول متوسط قدره 60.8 سنتاً. من المقرر أن تُقام مباراة إياب الدور نصف النهائي بدوري أبطال أوروبا بين بايرن ميونيخ وباريس سان جيرمان في 7 مايو عند

GateNewsمنذ 43 د

تراجع عائد السوق الأمريكي في Polymarket، ويُنظر إلى الرئيس التنفيذي Justin Hertzberg باعتباره دوراً شكلياً

بحسب موقع The Information، أدت توسّعات Polymarket في الولايات المتحدة إلى أداء دون المستوى منذ عودتها إلى السوق عبر الاستحواذ على بورصة منظمة للمشتقات، حيث يتراجع حصتها السوقية مقارنةً بالمنافس Kalshi. تقتصر مسؤوليات الرئيس التنفيذي Justin Hertzberg في المقام الأول على توقيع الوثائق التنظيمية، wi

GateNewsمنذ 2 س

Blockchain.com تطلق SnapMarkets في ظل تزايد نشاط أسواق التوقعات

أطلقت Blockchain.com SnapMarkets، وهي منصة لتداول أسواق التنبؤ. وتأتي عملية الإطلاق بالتزامن مع موجة متزايدة من أسواق التنبؤ، وفقاً للمادة المصدر. البيئة التنظيمية يجري توسع أسواق التنبؤ في ظل توترات تنظيمية. وتواجه أسواق التنبؤ مخاطر…

CryptoFrontierمنذ 3 س

يطلق بروفيت سوق تنبؤات مدعومًا بالذكاء الاصطناعي مع شريحة تداول حي بقيمة 10,000 دولار اليوم

بحسب MetaversePost، أطلق Prophet سوق تنبؤ مدعوم بالذكاء الاصطناعي اليوم (6 مايو) مع تخصيص 10,000 دولار من USDC للتداول المباشر. يمكن للمستخدمين التداول مباشرةً مقابل طرف مقابل للذكاء الاصطناعي يولّد تسعيراً قائماً على الاحتمالات لكل سوق، مع تسوية بعض العقود خلال 24

GateNewsمنذ 6 س

من المتوقع أن تتراوح القيمة المخففة بالكامل (FDV) لليوم الأول من MegaETH بين 1.5 مليار و2 مليار دولار، وتُظهر سوق التنبؤات لدى Gate ذلك

وبحسب بيانات أسواق التنبؤ التابعة لـ Gate، يُتوقع أن تنخفض القيمة التقديرية بالكامل ليوم MegaETH الأول (FDV) بين 1.5 مليار دولار و2 مليار دولار. وقد ولّدت خيار ">$1.5B" ما يقارب 2.18 مليون دولار في حجم التداول مع نتيجة "نعم"، بينما يُظهر خيار ">$2B" 9.057 مليون دولار في

GateNewsمنذ 6 س
تعليق
0/400
لا توجد تعليقات