Bản gốc tiêu đề：《Polymarket PnL Chính Xác Tính Toán: Tại Sao Bạn Có Thể Đang Tính Lỗi Lần Nữa》
Tác giả bản 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 hoặc thua lỗ.

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, trang phân tích của bên thứ ba cũng hiển thị thứ hạ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, dùng phương pháp sai để tính ra 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à ký hiệu lợi nhuận lỗ còn bị đảo ngược.

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: gọi API /positions, cộng tổng các trường cashPnl (lãi lỗ tiền mặt).

Thử nghiệm thực tế với 3 địa chỉ trong top 15:

swisstony: tổng cashPnl +$35,000, nhưng 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, ký hiệu đảo ngược

gmanas: tổng cashPnl -$2,64 triệu, thứ hạng thực tế +$5,02 triệu, ký hiệu đảo ngược

Ba địa chỉ này, hai trong số đó ký hiệu lợi nhuận lỗ bị đảo ngược trực tiếp.

Nguyên nhân: API /positions trả về trường cashPnl không bao gồm các lợi nhuận đã đóng hoặc đã đổi lấy USDC. Các vị thế thắng đã tự động được rút về USDC, và vị thế đó sẽ 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, thường có phần 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 đóng.

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 lớn 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 đến đâu, kết luận vẫn là: đừng 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.

Một txHash (băm giao dịch) xuất hiện nhiều bản ghi, phản ứng đầu tiên của người bình thường là: trùng lặp, loại bỏ.

Không thể làm vậy. 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, và 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, rõ ràng một giao dịch có nhiều sự kiện chuyển USDC độc lập, mỗi cái đều là một giao dịch thực.

Kết luận: không thể chỉ dựa vào txHash để loại bỏ. Để tính PnL, hãy cộng trực tiếp dữ liệu gốc từ /activity.

Sai lầm 4: Trang offset có giới hạn

Khi dùng API /activity để phân trang, dùng offset (độ lệch)? Trên 3000 bản ghi sẽ báo lỗi 400. Trong tài liệu không đề cập.

Ba địa chỉ trên đều xác nhận: GET /activity?offset=3100 trả về lỗi HTTP 400, thông báo max historical activity offset of 3000 exceeded. Các người chơi lớn có hàng chục nghìn giao dịch, 3000 là không đủ.

Dùng tham số end (gửi timestamp của bản ghi cuối cùng của trang trước - 1) để làm con trỏ 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 chưa đóng). Nhưng nếu chênh lệch rõ ràng lớn hơn, 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 bằng dòng tiền của một địa chỉ gần như trùng khớp với kết quả trả về của lb-api. Nếu chênh lệch lớn, hãy kiểm tra lại xem đã hoàn tất phân trang (sai lầm 4), hoặc đã dùng đúng trường (sai lầm 1-2).

Cách làm đúng

Sau khi thử nhiều phương pháp khác nhau, tôi xác nhận cách đáng tin cậy nhất là tổng hợp dòng tiền qua 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) + Rút tiền (REDEEM) + Gộp (MERGE) + Trả lại maker (MAKER_REBATE) + Thưởng (REWARD) - Tổng (giao dịch mua) - Phân chia (SPLIT) + Giá trị thị trường vị thế

· Giao dịch mua (TRADE BUY): chi tiêu USDC để mua token

· Giao dịch bán (TRADE SELL): bán token thu USDC

· RÚT (REDEEM): rút USDC từ vị thế thắng

· PHÂN CHIA (SPLIT): tạo token từ USDC (chi tiêu)

· GỘP (MERGE): hợp token về USDC (thu nhập)

· TRẢ LẠI maker (MAKER_REBATE): tiền thưởng maker

· THƯỞNG (REWARD): thưởng hoặc airdrop

· Nguồn dữ liệu:

GET /activity?user=<địa chỉ>&limit=500, phân trang bằng end, cộng tổng theo loại.

· Giá trị thị trường 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 được coi là chính xác. Chênh lệch do biến động giá trị thị trường chưa đóng.

Xác nhận: Thử nghiệm với top 15 địa chỉ

Sau khi tính bằng phương pháp 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.

Sau khi phương pháp này hoạt động chính xác, tôi đã dùng nó để phân tích hàng trăm địa chỉ lớn về 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 tính lợi nhuận đã đóng, ký hiệu có thể đảo ngược

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 trừ theo txHash → Không đúng, bỏ sót fill thực sự trên 100 đô la

Phân trang offset + cộng tổng → Không đúng, dữ liệu bị cắt, trên 3000 báo lỗi

Phương pháp dòng tiền API → Hiện là đáng tin cậy nhất, sai lệch < $10

Bước đầu của người làm lượng tử không phải là 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 định kỳ kiểm tra chéo kết quả của bạn qua API bảng xếp hạng.

Liên kết bài viết gốc

Nhấn để 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:

Nhóm Telegram theo dõi: https://t.me/theblockbeats

Nhóm Telegram trao đổi: https://t.me/BlockBeats_App

Tài khoản chính thức Twitter: https://twitter.com/BlockBeatsAsia