原文标题：《Polymarket PnL 精准计算：为什么你算的盈亏可能全是错的》
原文作者：Leo，加密分析师

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

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

ความเบี่ยงเบนมันรุนแรงแค่ไหน? อันดับ 3 ของตาราง kch123 คำนวณด้วยวิธีผิด ขาดทุน 3.5 แสนดอลลาร์ แต่กำไรจริง 1.14 ล้านดอลลาร์ ไม่ใช่แค่ต่างกันไม่กี่เปอร์เซ็นต์ — แต่สัญลักษณ์ของกำไรขาดทุนกลับกันหมด

บทความนี้จะแยกแต่ละจุดที่ผมเคยเจอมาอธิบาย ทำทั้งคนเทรด ทำเครื่องมือ และดูอันดับ ก็ต้องเจอในที่สุด

จุดที่ 1: cashPnl ไม่รวมกำไรขาดทุนที่เคลียร์แล้ว

วิธีที่ตรงที่สุดคือดึงข้อมูล /positions แล้วรวมฟิลด์ cashPnl (กำไรขาดทุนเป็นเงินสด)

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

swisstony: รวม cashPnl +$35,000 แต่ในอันดับจริง +$5.6 ล้าน ต่างกัน 158 เท่า

kch123: รวม cashPnl -$3.52 แสน แต่ในอันดับจริง +$11.4 ล้าน สัญลักษณ์กลับกัน

gmanas: รวม cashPnl -$2.64 แสน แต่ในอันดับจริง +$5.02 ล้าน สัญลักษณ์กลับกัน

ทั้งสามที่อยู่ สองรายสัญลักษณ์ของกำไรขาดทุนก็กลับกันไปแล้ว

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

คุณคิดว่าคำนวณกำไรขาดทุนทั้งหมดแล้ว จริงๆ แล้วได้แค่ส่วนที่ยังไม่เคลียร์เท่านั้น

จุดที่ 2: ฟิลด์ makerPnl กับเงินสดบน链ไม่ตรงกัน

ข้อมูลการเทรดใน JSONL มีฟิลด์ makerPnl (กำไรขาดทุนจากการเป็นผู้สร้างตลาด) ชื่อก็เหมือนจะใช้คำนวณ PnL แต่ไม่ใช่

ผมสังเกตในข้อมูลการเป็นผู้สร้างตลาดว่า ผลรวมของ makerPnl ที่คำนวณออกมานั้นต่างจากผลลัพธ์ของการคำนวณเงินสดบน链เป็นจำนวนมาก แนวโน้มอาจแตกต่างกันตามแต่ละสถานการณ์ แต่ทิศทางตรงกัน: กลไกการคำนวณ makerPnl ภายในไม่ตรงกับการเคลื่อนไหวของ USDC จริงบน链

ไม่ว่าจะเบี่ยงเบนมากแค่ไหน สรุปคือ: ห้ามใช้ฟิลด์นี้คำนวณ PnL

จุดที่ 3: ห้ามลบซ้ำโดยใช้ txHash

นี่เป็นสิ่งที่ตรงกันข้ามกับความรู้สึกธรรมดา

ถ้า txHash (รหัสธุรกรรม) ปรากฏหลายรายการ คนทั่วไปจะคิดว่าเป็นข้อมูลซ้ำ ควรลบซ้ำ

แต่ไม่ใช่แบบนั้น. CLOB (สมุดคำสั่งบน链) ของ PM สามารถจับคู่คำสั่งหลายคำสั่งในธุรกรรมเดียวกันได้ รายการหลายรายการภายใต้ txHash เดียวกันเป็น fill จริงที่แยกกัน

ก่อนหน้านี้ผมลบซ้ำโดยใช้ txHash + asset ทำให้ซื้อขายด้าน BUY ขาดไป 133 ดอลลาร์ ไปตรวจสอบบน Polygon ก็พบว่ามีหลาย event ของ USDC Transfer ที่แยกกันในแต่ละ txHash แต่ละรายการเป็นการซื้อขายจริง

สรุป: ห้ามลบซ้ำโดยใช้ txHash เพียงอย่างเดียว ต้องรวมข้อมูล /activity ทั้งหมดเพื่อคำนวณ PnL

จุดที่ 4: การเลื่อนหน้าด้วย offset มีขีดจำกัด

การเลื่อนหน้าข้อมูล /activity ด้วย offset (ค่าชดเชย) ถ้าเกิน 3000 รายการ จะขึ้นข้อผิดพลาด 400 ซึ่งไม่ได้ระบุไว้ในเอกสาร

ทั้งสามที่อยู่ด้านบนได้รับการทดสอบแล้ว: GET /activity?offset=3100 จะได้ HTTP 400 ข้อความผิดพลาดว่า “max historical activity offset of 3000 exceeded” ผู้ใช้งานระดับหัวแถวมักมีธุรกรรมหลายหมื่นรายการ 3000 รายการจึงไม่เพียงพอ

ใช้พารามิเตอร์ end (ส่ง timestamp ของรายการสุดท้ายในหน้าก่อน - 1) เพื่อเลื่อนหน้าด้วย cursor ก็ไม่มีขีดจำกัด

จุดที่ 5: ความแตกต่างของเกณฑ์ PnL ในอันดับ

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

ส่วนใหญ่ความแตกต่างอยู่ในไม่เกิน 10 ดอลลาร์ (จากความผันผวนของมูลค่าตำแหน่งแบบเรียลไทม์) แต่ถ้าความแตกต่างชัดเจนมากขึ้น สาเหตุอาจเป็น: ช่วงเวลาการรวมข้อมูลในอันดับ, การรีเฟรชแคชล่าช้า, หรือผู้ใช้ผูกหลาย proxy wallet

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

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

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

สูตร:

PnL = SUM(TRADE where side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE where side=BUY) - SUM(SPLIT) + มูลค่าตำแหน่ง

· TRADE BUY: ใช้ USDC ซื้อโทเค็น (ค่าใช้จ่าย)

· TRADE SELL: ขายโทเค็นคืน USDC (รายรับ)

· REDEEM: ถอน USDC จากตำแหน่งที่ชนะ (รายรับ)

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

· MERGE: รวมโทเค็นกลับเป็น USDC (รายรับ)

· MAKER_REBATE: ค่าคืนจาก Maker (รายรับ)

· REWARD: รางวัล/airdrops (รายรับ)

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

GET /activity?user=