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 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ô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à thậm chí không tính đúng được mình đã kiếm được bao nhiêu tiền.

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 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 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, đảo chiều ký hiệu

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

Ba địa chỉ này, hai trong số đó ký hiệu lợi nhuận lỗ đã bị đả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ả. Các vị thế thắng đã tự động được hoàn lại thành USDC, thì 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ỗ nổi.

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

Dữ liệu giao dịch JSONL có trường makerPnl (lợi nhuận maker), tên gọi là để tính PnL. Đừng tin.

Trong dữ liệu market, 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. 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à: đừ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 tự nhiên là: dữ liệu trùng, loại bỏ trùng.

Nhưng không được làm thế. CLOB của PM (sổ lệnh giới hạn trên chuỗi) có thể khớp nhiều lệnh maker trong một giao dịch trên chuỗi. Nhiều bản ghi cùng một 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, thì phía mua đã thiếu 133 đô la. 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 USDC Transfer độ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 trực tiếp dữ liệu gốc từ /activity.

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

Phân trang /activity dù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: max historical activity offset of 3000 exceeded. Các nhà giao dịch 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 bản ghi cuối cùng của trang trước - 1) để phân trang theo con trỏ, không có giới hạn.

Sai lầm 5: Sự khác biệt trong cách tính 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 chút.

Trong đa số 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 rõ rệt 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ế, phương pháp tính theo dòng tiền cho một địa chỉ cho ra kết quả gần như chính xác với API lb-api.polymarket.com/profit?window=all&address=X. Nếu chênh lệch lớn, hãy kiểm tra lại các bướ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, 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, chỉ cần tính từ dữ liệu giao dịch gốc.

Công thức:

PnL = Tổng (Giao dịch bán) + Tổng (Hoàn trả) + Tổng (Hợp nhất) + Tổng (Hoàn tiền Maker) + Tổng (Phần thưởng) - Tổng (Giao dịch mua) - Tổng (Chia nhỏ) + 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

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

· Chia nhỏ (SPLIT): USDC tạo thành token (chi phí)

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

· Hoàn tiền Maker (MAKER_REBATE): rebate của Maker (thu nhập)

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

· Nguồn dữ liệu:

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

· Giá trị thị trường vị thế:

Gọi 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 nhận: Top 15 trong bảng xếp hạng

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 ổ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. Kết quả khác hẳn.

Tổng kết

SUM(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 trường makerPnl → Không đúng, không khớp dòng tiền trên chuỗi

Tính theo txHash sau khi loại trùng → Không đúng, mất hơn 100 đô la, bỏ sót fill thực

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, chênh lệch < $10

Bước đầu để 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 chính xác.

Link 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 thảo luận: https://t.me/BlockBeats_App

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