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

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

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

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

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

กับดัก 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 ส่งคืน cashPnl ที่ไม่รวมกำไรขาดทุนที่เคลียร์แล้ว (realized PnL) กำไรที่ได้จากตำแหน่งที่ชนะจะถูกถอนออกเป็น USDC อัตโนมัติ ตำแหน่งนั้นก็จะหายไปจากข้อมูล API เหลือไว้แต่ตำแหน่งที่ยังไม่ปิด ซึ่งมักเป็นตำแหน่งที่ขาดทุนอยู่

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

กับดัก 2：ฟิลด์ makerPnl กับเงินสดบน链ไม่ตรงกัน

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

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

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

กับดัก 3：ไม่ควรลบซ้ำโดยใช้ txHash เป็นหลัก

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

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

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

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

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

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

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

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

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

กับดัก 5：ความแตกต่างของเกณฑ์ PnL ในอันดับ

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

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

จากการทดสอบ ผมพบว่าการคำนวณด้วยวิธี cash flow ให้ผลลัพธ์ของ PnL ของที่อยู่เดียวกันกับ API ของ 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=