Bản gốc tiêu đề：《Tính Toán Lãi Lỗ Chính Xác của Polymarket: Tại Sao Bạn Có Thể Đang Tính Sai Lợi Nhuận Thật Sự》
Tác giả gốc: Leo, nhà phân tích mã hóa
Tôi đã tự phát triển hệ thống giao dịch tự động trên Polymarket được nửa năm, và sai lầm lớn nhất không phải chiến lược thất bại, mà là không thể tính đúng số tiền mình đã kiếm được.
Không phải tôi kém. Chính PnL của PM đã là một mối nguy hiểm. API chính thức cung cấp số liệu cho bạn là sai, các trang phân tích bên thứ ba hiển thị thứ hạng cũng sai. Bạn tự viết script để tính? Khả năng cao vẫn sai.
Sai lệch lớn đến mức nào? Người đứng thứ 3 trong bảng xếp hạng kch123, tính theo phương pháp sai đã lỗ 3,5 triệu đô la, trong khi lợi nhuận thực tế là 11,4 triệu đô la. Không phải chênh lệch vài phần trăm—mà là dấu hiệu lợi nhuận lỗ đã bị đảo ngược hoàn toàn.
Bài viết này sẽ phân tích từng sai lầm tôi đã gặp phải. Dành cho những người giao dịch, viết công cụ, xem bảng xếp hạng, sớm muộn cũng sẽ gặp.
Sai lầm 1: cashPnl không bao gồm lợi nhuận đã thanh toán
Cách làm trực quan nhất: lấy API /positions, cộng dồn trường cashPnl (lợi nhuận tiền mặt).
Thử nghiệm thực tế với 3 địa chỉ trong top 15:
swisstony: tổng cashPnl +$35,000, thứ hạng thực tế +$5,6 triệu, chênh lệch 158 lần
kch123: tổng cashPnl -$3,52 triệu, thứ hạng thực tế +$11,4 triệu, đổi dấu
gmanas: tổng cashPnl -$2,64 triệu, thứ hạng thực tế +$5,02 triệu, đổi dấu
Ba địa chỉ này, hai trong số đó đã đổi dấu lợi nhuận/lỗ.
Nguyên nhân: API /positions trả về cashPnl không bao gồm các lợi nhuận đã đóng hoặc đã hoàn trả. Các vị thế thắng đã tự động hoàn trả bằng USDC, sau đó vị thế đó biến mất khỏi phản hồi API. Những gì còn lại là các vị thế chưa thanh toán hết—thường là lỗ chưa thực hiện.
Bạn nghĩ đang tính toàn bộ lợi nhuận/lỗ, thực ra chỉ lấy phần chưa thanh toán.
Sai lầm 2: Trường makerPnl không khớp với dòng tiền trên chuỗi
Trong dữ liệu JSONL của giao dịch có trường makerPnl (lợi nhuận maker), tên gọi là để tính PnL. Đừng tin.
Trong dữ liệu thị trường của tôi, tổng makerPnl tính ra khác biệt một mức so với kết quả tính dựa trên dòng tiền trên chuỗi. Hệ số cụ thể có thể thay đổi theo từng trường hợp, nhưng hướng chung là: logic tính makerPnl bên trong không phù hợp với dòng USDC thực tế.
Dù chênh lệch lớn thế nào, kết luận vẫn là: Không nên dùng trường này để tính PnL.
Sai lầm 3: Không thể chỉ dựa vào txHash để loại bỏ trùng lặp
Điều này trái với trực giác nhất.
Một txHash (băm giao dịch) xuất hiện nhiều bản ghi, phản ứng tự nhiên là: dữ liệu trùng lặp, loại bỏ.
Nhưng không được làm thế. CLOB của PM (sổ lệnh giới hạn trên chuỗi) trong một giao dịch có thể khớp nhiều lệnh maker, nhiều bản ghi dưới cùng một txHash là các fill thực sự riêng biệt.
Trước đây tôi đã loại trừ dựa trên txHash + asset, nhưng đã bỏ sót 133 đô la ở phía mua. Khi kiểm tra trên chuỗi Polygon, một băm giao dịch thực sự có nhiều sự kiện Transfer USDC độc lập, mỗi cái là một giao dịch thực sự.
Kết luận: Không thể chỉ dựa vào txHash để loại bỏ trùng lặp. Để tính PnL, hãy cộng dồn dữ liệu gốc từ /activity.
Sai lầm 4: Trang offset có giới hạn
Trong API /activity, dùng offset để phân trang? Nếu vượt quá 3000 dòng sẽ báo lỗi 400. Trong tài liệu không đề cập.
Ba địa chỉ trên đều đã xác minh: GET /activity?offset=3100 trả về HTTP 400, thông báo lỗi: max historical activity offset of 3000 exceeded. Các trader lớn thường có hàng chục nghìn giao dịch, 3000 là không đủ.
Dùng tham số end (gửi timestamp của giao dịch cuối cùng của trang trước - 1) để phân trang không giới hạn.
Sai lầm 5: Sự khác biệt về tiêu chuẩn PnL trong bảng xếp hạng
Bạn tính PnL của một địa chỉ rồi so sánh với bảng xếp hạng, có chênh lệch chút.
Trong hầu hết các trường hợp, chênh lệch dưới 10 đô la (do biến động giá trị thị trường của các vị thế). Nhưng nếu chênh lệch lớn hơn rõ ràng, nguyên nhân có thể là: khung thời gian tổng hợp của bảng xếp hạng, độ trễ làm mới cache, hoặc người dùng liên kết nhiều ví proxy.
Thử nghiệm thực tế, PnL tính theo dòng tiền của một địa chỉ gần như trùng khớp với kết quả API lb-api. Nếu chênh lệch lớn, hãy kiểm tra lại việc phân trang (sai lầm 4), hoặc dùng sai trường (sai lầm 1-2).
Cách làm đúng
Sau nhiều thử nghiệm, tôi xác nhận phương pháp đáng tin cậy nhất là tổng hợp dòng tiền từ Data API. Không cần các trường tính trước, trực tiếp tính từ dữ liệu giao dịch gốc.
Công thức:
PnL = Tổng (giao dịch bán) + Thu hồi + Gộp + Hoàn trả maker + Thưởng + Trợ cấp - Tổng (giao dịch mua) - Tách ra + Giá trị vị thế
· Giao dịch mua (TRADE BUY): Chi tiêu USDC để mua token (chi phí)
· Giao dịch bán (TRADE SELL): Bán token thu USDC (thu nhập)
· REDEEM: Rút USDC từ vị thế thắng (thu nhập)
· SPLIT: Đúc USDC thành token (chi phí)
· MERGE: Gộp token về USDC (thu nhập)
· MAKER_REBATE: Hoàn tiền maker (thu nhập)
· REWARD: Phần thưởng/airdrop (thu nhập)
· Nguồn dữ liệu:
GET /activity?user=<địa chỉ>&limit=500, phân trang bằng end, cộng dồn theo loại.
· Giá trị vị thế:
GET /positions?user=<địa chỉ>, tính theo số lượng × giá hiện tại.
· Kiểm tra chéo:
So sánh kết quả tính với API bảng xếp hạng của Polymarket (lb-api.polymarket.com/profit?window=all&address=X), chênh lệch < $10 là chấp nhận được. Chênh lệch do biến động giá trị thị trường của các vị thế.
Xác minh: Top 15 địa chỉ thực tế
Sau khi tính theo dòng tiền, so sánh với API bảng xếp hạng:
swisstony: phương pháp dòng tiền +$5,601,000, bảng xếp hạng +$5,601,000, chênh lệch < $10
kch123: phương pháp dòng tiền +$11,396,000, bảng xếp hạng +$11,396,000, chênh lệch < $10
gmanas: phương pháp dòng tiền +$5,024,000, bảng xếp hạng +$5,024,000, chênh lệch < $10
Ba địa chỉ này, sai số đều dưới $10, chênh lệch chủ yếu do biến động giá trị thị trường của các vị thế.
Sau khi phương pháp này hoạt động chính xác, tôi đã phân tích hàng trăm địa chỉ lớn để xác định lợi nhuận thực. Đó là chuyện khác rồi.
Tổng kết
SUM(cashPnl) từ /positions → Không đúng, không bao gồm lợi nhuận đã thanh toán, có thể đổi dấu
Tổng trường makerPnl → Không đúng, không khớp dòng tiền trên chuỗi
Tính sau khi loại bỏ trùng bằng txHash → Không đúng, mất các fill thực
Phân trang offset + cộng dồn → Không đúng, dữ liệu bị cắt, >3000 báo lỗi
Phương pháp dòng tiền API → Hiện là đáng tin cậy nhất, chênh lệch < $10
Bước đầu để làm quants không phải tìm alpha. Mà là xác nhận bạn tính đúng.
Tất cả đều dựa trên thực tế, không phải lý thuyết. API của PM có thể thay đổi bất cứ lúc nào, nên thường xuyên kiểm tra chéo kết quả của bạn qua API bảng xếp hạng.
Link bài gốc
Click để biết thêm về các vị trí tuyển dụng của BlockBeats
Chào mừng gia nhập cộng đồng chính thức của BlockBeats:
Telegram nhóm theo dõi: https://t.me/theblockbeats
Telegram nhóm trao đổi: https://t.me/BlockBeats_App
Twitter chính thức: https://twitter.com/BlockBeatsAsia
