เรื่องหัวข้อต้นฉบับ: "การคำนวณกำไรขาดทุน (PnL) แม่นยำของ Polymarket: ทำไมคุณอาจคำนวณกำไรขาดทุนผิดไปทั้งหมด"

ฉันได้ทดลองใช้งานระบบการซื้อขายอัตโนมัติของ Polymarket เป็นเวลาหนึ่งปี และความยากลำบากที่สุดที่เผชิญก็ไม่ใช่ในการกำหนดกลยุทธ์ แต่เป็นในการคำนวณเงินที่ได้เอาไว้ว่าได้เท่าไร

ไม่ใช่เพราะว่าฉันโง่ แต่เพราะการคำนวณ PnL ของ PM เองเป็นพื้นที่รองรับสถานการณ์ ข้อมูลตัวเลขที่ API ทางการให้คุณเป็นข้อมูลที่ผิดพลาด อันดิบที่เว็บไซต์วิเคราะห์บางเว็บมุ่ง แสดงตำแหน่งก็เป็นข้อมูลที่ผิดกัน คุณจะเขียนสคริปต์เองมาคำนวณ? มีโอกาสสูงว่าจะผิด

ความคลาดเคลื่อนมีระดับเป็นเท่าไรล่ะ? เช่นผู้อยู่อันดับ 3 ชื่อ kch123 ที่คำนวณแล้วพบว่าขาดทุนถึง $3.5 ล้าน แต่กำไรแท้มีมูลค่าถึง $11.4 ล้าน ไม่ใช่แค่มีค่าผิดๆ หลายร้อยเปอร์เซ็นต์ — แต่มีการย้อนกลับที่คำนวณกำไรขาดทุนเป็นกำไรหรือขาดทุน

บทความนี้จะอธิบายถอดแต่งความผิดพลาดทุกรูปแบบที่ฉันได้เผชิญ เหมาะสำหรับผู้ที่ทำการซื้อขาย ผู้เขียนเครื่องมือ และผู้ชมตำแหน่ง เต็มที่

ความผิดพลาดที่ 1: cashPnl ไม่รวมกำไรที่ได้แล้ว

เป็นวิธีที่ถูกต้องที่สุดน่าจะเป็น: เรียกรายงาน API /positions และรวบรวมค่า cashPnl (กำไรขาดทุนเงินสด)

ทดสอบกับที่อยู่ 15 อันดับแรกของตาราง:

swisstony: รวบรวม cashPnl +$3.5 หมื่น ตำแหน่งจริง +$5.6 ล้าน ความคลาดเคลื่อน 158 เท่า

kch123: รวบรวม cashPnl -$3.52 ล้าน ตำแหน่งจริง +$11.4 ล้าน การกลับด้าน

gmanas: รวบรวม cashPnl -$2.64 ล้าน ตำแหน่งจริง +$5.02 ล้าน การกลับด้าน

ที่อยู่สามแห่ง อย่างน้อยสองในรายการ กำไรขาดทุนถูกกลับด้านตรงๆ

เหตุผล: /positions ค่าตอบสนองของอินเตอร์เฟซส่งค่า cashPnl ที่ไม่รวมกำไรที่ได้แล้วจากการปิด/ได้รับ ตำแหน่งที่ชนะถูกแลก USDC โดยอัตโนมัติ ไปแล้ว position นี้ก็หายไปจากการตอบสนองของ API มีอยู่แต่ตำแหน่งที่ค้างอยู่ที่ยังไม่ถูกจัดการขึ้น — บางครั้งมักเป็นลำดับขาดทุน

คุณคิดว่าคุณกำลังคำนวณกำไรขาดทุนทั้งหมด แต่คุณแค่ได้รับส่วนที่ยังไม่ได้บัญชีเท่านั้น

ข้อ บ่อน 2: ช่อง makerPnl และกระแสเงินสดบนเชือกไม่สอดคล้องกัน

ใน JSONL ข้อมูลการซื้อขายมีช่อง makerPnl ซึ่งภายในชื่อเหมือนกับคำ PnL ที่คุณใช้ อย่าไว้วางใจ

ฉันมองเห็นว่าในข้อมูลการซื้อขายเชิงเส้น SUM(makerPnl) ที่คำนวณออกมาไม่สอดคล้องกับผลการตรวจสอบกระแสเงินสดบนเชือกอย่างละเอียด ขนาดการสูบศูนย์อาจแตกต่างกัน แต่ทิศทางเดียวกัน: ตรรกะการคำนวณภายใน makerPnl ไม่สอดคล้องกับการกระทำ USDC จริงๆ

ไม่ว่าจะมีการเบนเท่าใด น่าเชื่อกันว่า: อย่าใช้ช่องนี้คำนวณ PnL

ข้อ บ่อน 3: ไม่สามารถตรวจสอบคำพาทีละ txHash

ส่วนที่น่าแปลกใจที่สุด

มีบันทึกหลายรายการใน txHash เดียวกัน คนปกติโดยทั่วไปจะคิด: ข้อมูลที่ซ้ำซ้อน ต้องตรวจสอบ

ไม่ควรทำเช่นนั้น CLOB ของ PM (หน้ากระดานคำสั่ง limit order บนเชือก) สามารถจับคู่คำสั่ง maker หลายคำสั่งเงินตรงเดียวกัน txHash เดียวกันที่มีการบันทึกหลายรายการเป็นการกระทำสำเร็จแท้จริง

ก่อนหน้านี้ ฉันคำนวณตาม txHash + asset ยาวน้อยไป $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 (นับตั้งแต่ timestamp ของรายการก่อนหน้าสุดท้ายของหน้า) เพื่อแบ่งหน้าผลลัพธ์ ไม่มีขีดจำกัด

ข้อผิดพลาด 5: ความแตกต่างของ PnL ในอันดับชั้น

เมื่อคุณคำนวณ PnL ของที่อยู่หนึ่ง แล้วไปเปรียบเทียบกับอันดับชั้น คุณพบว่ามีความแตกต่างเล็กน้อย

ในกรณีส่วนมาก ความแตกต่างจะอยู่ในช่วง $10 หรือน้อยกว่า (มาจากการเปลี่ยนแปลงในมูลค่าของตำแหน่งที่ถืออยู่ในตลาดเป็นเวลาจริง) แต่หากความแตกต่างมีขนาดใหญ่มากกว่านั้น สาเหตุอาจเป็นเพราะ: หน้าต่างการรวบรวมของอันดับชั้น เวลาชะลมของแคช หรือผู้ใช้เชื่อมต่อกับพร็อกซีวอลเล้ทหลายรายการ

จากการทดสอบโดยตรง ผล PnL ของที่อยู่เดียวกันที่คำนวณด้วยวิธีการสะสมเงินสด ตรงกับค่าที่ส่งกลับจาก lb-api อย่างมาก หากความต่างของผลออกมามาก ให้ตรวจสอบให้แน่ใจก่อนว่าการแบ่งหน้าเสร็จสมบูรณ์ (ข้อผิดพลาด 4) หรือมีการใช้ฟิลด์ผิด (ข้อผิดพลาด 1-2)

วิธีการที่ถูกต้อง

หลังจากลองวิธีการต่าง ๆ ฉันพบว่าวิธีที่เชื่อถือได้ที่สุดคือสรุปกระแสเงินสดของ Data API โดยที่ไม่คำนวณผลลัพธ์ล่วงหน้าใด ๆ และเข้าถึงเพียงแค่บันทึกธุรกรรมเดิม เพื่อคำนวณค่ารายได้และค่าใช้จ่าย

สูตร:

PnL = ผลรวม(TRADE ที่มี side=SELL) + ผลรวม(REDEEM) + ผลรวม(MERGE) + ผลรวม(MAKER_REBATE) + ผลรวม(REWARD) - ผลรวม(TRADE ที่มี side=BUY) - ผลรวม(SPLIT) + มูลค่าตำแหน่งถืออยู่ในตลาด

· TRADE BUY: ใช้ USDC ซื้อ token (ค่าใช้จ่าย)

· TRADE SELL: ขาย token แลกรับ USDC (รายได้)

· REDEEM: แลกรับคืน USDC ของตำแหน่งชนะเลิศ (รายได้)

· SPLIT: การโกง USDC เป็นคู่ token (ค่าใช้จ่าย)

· MERGE: การผสมคู่ token กลับเป็น USDC (รายได้)

· MAKER_REBATE: ส่วนลดค่าธรรมเนียมสำหรับ Maker (รายได้)

· REWARD: รางวัล/การแจกจ่ายฟรี (รายได้)

· แหล่งข้อมูล：

GET /activity?user=<address>&limit=500 ใช้ end ในการหน้า ดึงข้อมูลทั้งหมดแล้วรวมตามประเภท

· มูลค่าสำรองเงิน:

GET /positions?user=<address> ขนาด × ราคาปัจจุบัน

· การตรวจสอบแบบ Cross:

เปรียบเทียบผลลัพธ์การคำนวณกับ Polymarket ผ่าน API ของการจัดอันดับ (lb-api.polymarket.com/profit?window=all&address=X) ความแตกต่างน้อยกว่า $10 ถือว่าผ่าน เกิดจากความผันผวนของมูลค่าสำรองเงินแบบเรียลไทม์

การตรวจสอบ: ผลลัพธ์อันดับ 15 ในการทดสอบแบบจริง

หลังจากคำนวณด้วยวิธีการสายน้ำเงิน นำผลลัพธ์มาเปรียบเทียบกับ API อันดับ

swisstony: วิธีการสายน้ำเงิน +$560.1 ล้าน อันดับ +$560.1 ล้าน ความแตกต่างน้อยกว่า $10

kch123: วิธีการสายน้ำเงิน +$1139.6 ล้าน อันดับ +$1139.6 ล้าน ความแตกต่างน้อยกว่า $10

gmanas: วิธีการสายน้ำเงิน +$502.4 ล้าน อันดับ +$502.4 ล้าน ความแตกต่างน้อยกว่า $10

ความคลาดเคลื่อนของที่อยู่สามที่ระหว่าง $10 และกันมาจากผันผวนของมูลค่าสำรองเงินแบบเรียลไทม์

หลังจากที่วิธีการรันผ่าน ผมใช้มันสำรวจกำไรขาดทุนที่แท้จริงของที่อยู่บนด้านบนหลายร้อยอัน นั้นเป็นเรื่องอื่นๆ

สรุป

SUM(cashPnl) from /positions → ไม่ได้ เพราะไม่รวมกำไรที่ได้รับ สัญลักษณ์อาจเปลี่ยนเป็นตรงข้ามได้

การรวมผลรายการ makerPnl → ไม่ได้ เนื่องจากไม่สอดคล้องกับการสายน้ำเงินบนเชื่อม

คำนวณหลังจากลบ txHash ซ้ำกัน → ไม่ได้ $100+ ลบการแซงที่แท้จริง

ออฟเซ็ต หน้า หน้า + ผลรวม → ไม่ได้, ข้อมูลถูกตัด, >3000 ขัดข้อง

API ข้อมูล Cash Flow → ปัจจุบันเป็นที่เชื่อถือได้ที่สุด, <$10

ขั้นตอนแรกในการประยุกต์หุ้นคือไม่ใช่การค้นหาอัลฟา แต่เป็นการยืนยันว่าคุณคำนวณถูกต้องก่อน

ข้ามข้างต้นมาจากการเทรดด้วยข้อมูลจริง ไม่ใช่การแผนภาคภูมิ ในที่สุด API ของ PM อาจปรับพฤติกรรมได้ตลอดเวลา แนะนำให้ใช้ API ของอันดับอย่างสม่ำเสมอเพื่อตรวจสอบผลการคำนวณของคุณ

ลิงก์ข้อความต้นฉบับ

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia