Bản gốc tiêu đề: 《Polymarket PnL Chính Xác Tính Toán: Tại Sao Bạn Tính Lãi Lỗ Có Thể Đều Sai Bét》
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à ngay cả việc tính xem mình đã kiếm được bao nhiêu tiền cũng không chính xá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à ký hiệu lãi 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, 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 chiều ký hiệu

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

Ba địa chỉ, hai trong số đó ký hiệu lãi 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ị 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 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 lỗ nhà tạo lập thị trường), tên gọi là để tính PnL. Đừng tin.

Trong dữ liệu thị trường của 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ả tính dựa trên dòng tiền trên chuỗi, chênh lệch một số lượng lớn. Tỉ lệ chính xác có thể khác nhau tùy 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 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 của người bình thường là: dữ liệu trùng, loại bỏ trùng lặp.

Nhưng không thể làm vậy. Cơ chế CLOB (sổ lệnh giới hạn trên chuỗi) của PM có thể khớp nhiều lệnh maker trong một giao dịch chuỗi duy nhất, các bản ghi cùng txHash là các fill thực sự riêng biệt.

Trước đây tôi từng 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 đều là một giao dịch thực.

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

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

Giao diện /activity dùng offset để phân trang? Nếu vượt quá 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 minh: GET /activity?offset=3100 trả về lỗi HTTP 400, thông báo 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 đủ.

Sử dụng tham số end (gửi timestamp của bản ghi cuối cùng của trang trước - 1) để phân trang bằng con trỏ 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ó sự chênh lệch nhỏ.

Trong đa số trường hợp, chênh lệch dưới $10 (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ệt, 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 của 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 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 tính trước, lấy trực tiếp từ các giao dịch gốc để tính dòng tiền vào ra.

Công thức:

PnL = Tổng TRADE (bán) + Tổng REDEEM + Tổng MERGE + Tổng MAKER_REBATE + Tổng REWARD - Tổng TRADE (mua) - Tổng SPLIT + Giá trị thị trường vị thế

· TRADE MUA: chi tiêu USDC để mua token

· TRADE BÁN: bán token thu USDC (thu nhập)

· REDEEM: rút USDC từ vị thế thắng (thu nhập)

· SPLIT: USDC tạo thành token (chi tiêu)

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

· MAKER_REBATE: tiền thưởng của 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, dùng end để phân trang, sau khi lấy đủ toàn bộ, cộ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 coi như hợp lệ. Chênh lệch do biến động giá trị thị trường của các vị thế.

Xác minh: Thực tế 15 địa chỉ hàng đầu

Sau khi tính theo dòng tiền, so sánh chéo 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ỉ này đều có sai số 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 ổn định, tôi đã dùng nó để phân tích lợi nhuận thực của hàng trăm địa chỉ lớn. Đó là chuyện khác rồi.

Tổng kết

SUM(cashPnl) từ /positions → Không chính xác, không bao gồm lợi nhuận đã thanh toán, ký hiệu có thể đảo ngược

Tổng trường makerPnl → Không chính xác, không khớp dòng tiền trên chuỗi

Tính sau khi loại trừ theo txHash → Không chính xác, bỏ sót fill thực sự trên 100 đô la

Phân trang offset + cộng tổng → Không chính xác, 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, chênh lệch < $10

Bước đầu của giao dịch định lượng 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 khuyên bạn thường xuyên dùng API bảng xếp hạng để kiểm tra chéo kết quả của mình.

Link bài 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:

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

Telegram nhóm thảo luận: https://t.me/BlockBeats_App

Twitter chính thức: https://twitter.com/BlockBeatsAsia