Tính Toán Chính Xác Lợi Nhuận/Lỗ của Polymarket: Tại sao lợi nhuận của bạn có thể sai?

Tiêu đề gốc：《Polymarket PnL Chính Xác Tính Toán: Tại Sao Bạn Tính Lợi Nhuận Thua Lỗ Có Thể Đều Sai Bét》Tác giả gốc: Leo, nhà phân tích mã hóa

Tác giả gốc:律动BlockBeats

Nguồn gốc bài viết:

Đăng lại: Phương Tiện Tài Chính Mars

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 tôi gặp phải không phải là 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 vùng cấ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 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 vài phần trăm—mà là ký hiệu lợi nhuận lỗ còn đả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: 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ực tế trong bảng xếp hạng +$5,6 triệu, chênh lệch 158 lần

kch123: tổng cashPnl -$3,52 triệu, thực tế +$11,4 triệu, ký hiệu đảo ngược

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

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

Nguyên nhân: API /positions trả về trường cashPnl không bao gồm các lợi nhuận đã đóng/được hoàn trả (realized PnL). Các vị thế thắng lợi sau khi tự động hoàn trả bằng USDC thì 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—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 chain

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 maker, tôi quan sát thấy, tổng makerPnl tính ra khác biệt lớn so với kết quả kiểm tra dòng tiền trên chain. 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à: không dùng trường này để tính PnL.

Sai lầm 3: Không thể dựa vào txHash để loại bỏ trùng lặp

Điều này phản trực giác.

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

Nhưng không thể làm thế. Cơ chế CLOB (sổ lệnh giới hạn trên chain) của PM có thể khớp nhiều lệnh maker trong một giao dịch chain. 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 từng dựa vào txHash + asset để loại bỏ trùng lặp, nhưng đã bỏ sót 133 đô la ở phía mua. Kiểm tra trên 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 đề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, nên cộng dồn dữ liệu gốc từ /activity.

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

Giao diện /activity phân trang bằng offset? Quá 3000 bản ghi thì 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ề HTTP 400, thông báo lỗi: vượt quá giới hạn offset hoạt động lịch sử tối đa là 3000. Các người chơi lớn thường có hàng vạ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 có giới hạn.

Sai lầm 5: Sự khác biệt về tiêu chuẩn PnL của 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.

Trong hầu hết các trường hợp, chênh lệch trong khoảng 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 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ả API lb-api. Nếu chênh lệch lớn, trước tiên kiểm tra 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, 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 (TRADE với side=SELL) + Tổng (REDEEM) + Tổng (MERGE) + Tổng (MAKER_REBATE) + Tổng (REWARD) - Tổng (TRADE với side=BUY) - Tổng (SPLIT) + Giá trị thị trường vị thế

· TRADE BUY: chi tiêu USDC mua token

· TRADE SELL: bán token thu USDC

· REDEEM: hoàn trả USDC từ vị thế thắng

· SPLIT: đúc USDC thành token (chi tiêu)

· MERGE: hợp nhất token thành USDC (thu nhập)

· MAKER_REBATE: tiền thưởng maker (thu nhập)

· REWARD: thưởng/airdrop (thu nhập)

· Nguồn dữ liệu:

GET /activity?user=&limit=500, phân trang bằng end, cộng dồn theo loại rồi cộng tổng.

· Giá trị vị thế:

GET /positions?user=, 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 dưới 10 đô la được coi là chính xác. Chênh lệch chủ yếu do biến động giá trị thị trường.

Thử nghiệm thực tế với top 15:

Sau khi tính bằng dòng tiền, so sánh với API bảng xếp hạng:

swisstony: dòng tiền +$5,601,000, bảng xếp hạng +$5,601,000, chênh lệch < $10

kch123: dòng tiền +$11,396,000, bảng xếp hạng +$11,396,000, chênh lệch < $10

gmanas: dòng tiền +$5,024,000, bảng xếp hạng +$5,024,000, chênh lệch < $10

Ba địa chỉ sai lệch đều dưới 10 đô la, 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 ổn, tôi đã dùng nó phân tích hàng trăm địa chỉ lớn về lợi nhuận thực.

Tổng kết

Tổng cashPnl từ /positions → Không đúng, không tính lợi nhuận đã thanh toán, ký hiệu có thể đảo ngược

Tổng makerPnl → Không đúng, không khớp dòng tiền chain

Dựa vào txHash để loại bỏ trùng lặp → Không đúng, hơn 100 đô la, đã bỏ sót fill thực

Trang offset + cộng dồn → 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 tại đáng tin cậy nhất, dưới 10 đô la chênh lệch

Bước đầu tiên của người làm lượng hóa 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 kết quả của bạn qua API bảng xếp hạng để đảm bảo tính chính xác.