Tiêu đề gốc: "Tính toán chính xác PnL của Polymarket: Tại sao tính toán lãi và lỗ của bạn có thể sai hoàn toàn"
Tác giả gốc: Leo, Nhà phân tích tiền điện tử

Tôi đã tự nghiên cứu giao dịch tự động tại Polymarket trong nửa năm và cạm bẫy lớn nhất tôi gặp phải không phải là sự thất bại của chiến lược mà là tính toán sai số tiền tôi đã kiếm được.

Không phải tách trà của tôi. Bản thân cách tính toán PnL của PM đã là một bãi mìn. Các con số mà API chính thức cung cấp cho bạn là sai và thứ hạng được hiển thị bởi các trang web phân tích của bên thứ ba cũng sai. Bạn có viết kịch bản của riêng bạn? Nhiều khả năng nó vẫn sai.

Sự sai lệch đáng kinh ngạc đến mức nào? kch123, đứng thứ 3 trong danh sách, lỗ 3,5 triệu USD do tính sai phương pháp nhưng thực tế lại lãi 11,4 triệu USD. Nó không chỉ giảm một vài điểm phần trăm - các dấu hiệu lãi và lỗ bị đảo ngược.

Bài viết này phân tích mọi cạm bẫy mà tôi đã giẫm phải. Những người làm nghề giao dịch, viết công cụ, đọc bảng xếp hạng sớm muộn gì cũng sẽ gặp phải chúng.

Hố 1: cashPnl không chứa lợi nhuận đã thanh toán

Cách tiếp cận trực quan nhất: kéo giao diện /positions và tính tổng các trường cashPnl (lãi và lỗ tiền mặt).

Thực hiện phép đo thực tế của ba địa chỉ trong 15 địa chỉ hàng đầu của bảng xếp hạng:

swisstony: cashPnl sum +$35.000, xếp hạng thực tế +5,6 triệu USD, chênh lệch 158 lần

kch123: cashPnl sum -$3,52 triệu, xếp hạng thực tế +11,4 triệu đô la, ký hiệu đảo ngược

gmanas: tổng tiền mặt -2,64 triệu đô la, xếp hạng thực tế +5,02 triệu đô la, ký hiệu đảo ngược

Ba địa chỉ, hai biểu tượng lãi và lỗ được đảo ngược trực tiếp.

Lý do: CashPnl được trả về bởi giao diện /positions không chứa PnL đã nhận được đã được đóng/quy đổi. Sau khi vị trí chiến thắng được tự động đổi thành USDC, vị trí đó 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 ổn định - thường bị chi phối bởi các khoản lỗ thả nổi.

Bạn tưởng mình đang tính toán hết lãi lỗ nhưng thực tế bạn chỉ tính được phần chưa quyết toán.

Hố 2: Trường MakerPnl không nhất quán với dòng tiền trên chuỗi

Có trường MakerPnl (lãi và lỗ tạo ra thị trường) trong dữ liệu giao dịch JSONL. Tên được sử dụng để tính toán PnL cho bạn. Đừng tin điều đó.

Tôi quan sát thấy trong dữ liệu tạo thị trường rằng con số được tính bằng SUM (makerPnl) có độ lớn khác với kết quả tính toán dòng tiền trên chuỗi. Bội số cụ thể có thể khác nhau tùy theo kịch bản, nhưng hướng thì giống nhau: logic tính toán nội bộ của MakerPnl không khớp với luồng USDC thực tế.

Cho dù độ lệch có lớn đến đâu thì kết luận vẫn như nhau: không sử dụng trường này để tính PnL.

Hố 3: Bạn không thể chỉ sử dụng txHash để loại bỏ các bản sao

Đây là cách phản trực quan nhất.

Khi nhiều bản ghi xuất hiện trong cùng một txHash (băm giao dịch), phản ứng đầu tiên của người bình thường là: sao chép dữ liệu và xóa các bản sao.

Không thể làm được điều này. CLOB (sổ đặt hàng giới hạn giá chuỗi) của PM có thể khớp với nhiều đơn đặt hàng của nhà sản xuất trong một giao dịch trực tuyến và nhiều bản ghi trong cùng một txHash là những lần điền thực sự độc lập.

Tôi đã sử dụng txHash + nội dung để loại bỏ các bản sao và bên MUA đã thiếu $133. Đã xác minh trên chuỗi Polygon rằng thực sự có nhiều sự kiện Chuyển USDC độc lập trong hàm băm giao dịch, mỗi sự kiện tương ứng với một giao dịch thực.

Kết luận: Bạn không thể chỉ nhấn txHash để xóa các bản sao. Để tính toán PnL, hãy tính tổng trực tiếp dữ liệu thô/hoạt động.

Hố 4: Có giới hạn cho việc chuyển trang offset

Nếu giao diện /activity lật trang thì sử dụng offset (offset)? Nếu có hơn 3000 mục, lỗi 400 sẽ được báo cáo trực tiếp. Nó không được viết trong tài liệu.

Ba địa chỉ trên đều đã được xác minh: GET /activity?offset=3100 trả về HTTP 400 và thông báo lỗi đã vượt quá mức bù hoạt động lịch sử tối đa là 3000. Những người chơi hàng đầu thường thực hiện hàng chục nghìn giao dịch và 3.000 đơn giản là không đủ.

Sử dụng tham số end (chuyển dấu thời gian của mục cuối cùng ở trang trước - 1) để thực hiện chuyển trang con trỏ, không có giới hạn trên.

Hố 5: Sự khác biệt về tầm cỡ PnL trong danh sách xếp hạng

Sau khi bạn tính PnL của một địa chỉ, hãy vào danh sách xếp hạng để so sánh, bạn sẽ thấy nó hơi sai lệch một chút.

Sự khác biệt nằm trong khoảng 10 USD trong hầu hết các trường hợp (từ những biến động theo thời gian thực về giá trị thị trường của vị thế). Nhưng nếu khoảng cách lớn hơn đáng kể, các lý do có thể bao gồm: cửa sổ tổng hợp của bảng xếp hạng, độ trễ làm mới bộ đệm hoặc người dùng đã liên kết nhiều ví proxy.

Trong phép đo thực tế, PnL một địa chỉ được tính bằng phương pháp dòng tiền rất phù hợp với giá trị trả về của lb-api. Nếu có sự khác biệt lớn giữa các kết quả của bạn, trước tiên hãy kiểm tra xem việc lật trang đã hoàn tất chưa (ô 4) và liệu các trường có được sử dụng sai hay không (ô 1-2).

Phương pháp tiếp cận đúng

Sau khi thử nhiều phương pháp khác nhau, tôi đã xác minh rằng phương pháp đáng tin cậy nhất là tóm tắt dòng tiền API dữ liệu. Không có bất kỳ trường tính toán trước nào, dòng tiền vào và dòng tiền ra được tính trực tiếp từ hồ sơ giao dịch ban đầu.

Công thức:

PnL = SUM(THƯƠNG MẠI trong đó bên=BÁN) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(THƯỞNG) - SUM(THƯƠNG MẠI trong đó bên=BUY) - SUM(SPLIT) + giá trị thị trường vị trí

· MUA GIAO DỊCH: Chi USDC để mua token (xuất chi)

· BÁN GIAO DỊCH: Bán token để lấy lại USDC (thu nhập)

· ĐỔI: Đổi các vị trí chiến thắng để lấy USDC (thu nhập)

· SPLIT: USDC được đúc thành các cặp token (xuất chi)

· MERGE: Các cặp token được hợp nhất trở lại thành USDC (thu nhập)

· MAKER_REBATE: Giảm giá Maker (thu nhập)

· PHẦN THƯỞNG: Phần thưởng/airdrop (thu nhập)

· Nguồn dữ liệu:

GET /activity?user=