Perhitungan PnL Polymarket yang Akurat: Mengapa Perkiraan Keuntungan dan Kerugian Anda Bisa Salah?

Judul asli: 《Perhitungan PnL Polymarket yang Akurat: Mengapa Perhitungan Keuntungan dan Kerugianmu Bisa Sepenuhnya Salah》Penulis asli: Leo, analis kripto

Penulis asli:律动BlockBeats

Sumber asli:

Repost: Mars Finance

Saya telah melakukan otomatisasi trading mandiri di Polymarket selama setengah tahun, dan lubang terbesar yang saya pijak bukanlah strategi yang gagal, melainkan bahwa saya bahkan tidak bisa menghitung berapa banyak uang yang saya hasilkan dengan benar.

Bukan saya yang buruk. Masalahnya adalah perhitungan PnL di PM sendiri adalah area berbahaya. API resmi memberi angka yang salah, peringkat yang ditampilkan oleh situs analisis pihak ketiga juga salah. Kamu menulis skrip sendiri? Kemungkinan besar tetap salah.

Seberapa besar deviasinya? Peringkat ketiga, kch123, menghitung kerugian sebesar $3,5 juta dengan metode yang salah, padahal keuntungan sebenarnya adalah $11,4 juta. Bukan hanya selisih beberapa poin persentase—tanda keuntungan dan kerugian bahkan terbalik.

Artikel ini akan membongkar setiap lubang yang saya pijak. Bagi trader, pembuat alat, dan yang melihat peringkat, pasti akan menemukannya.

Lubang 1: cashPnl tidak mencakup keuntungan yang sudah diselesaikan

Pendekatan paling intuitif: tarik API /positions, jumlahkan bidang cashPnl (keuntungan dan kerugian tunai).

Mengambil tiga alamat teratas dari peringkat dan mengujinya secara langsung:

swisstony: jumlah cashPnl +$35.000, peringkat sebenarnya +$5,6 juta, selisih 158 kali

kch123: jumlah cashPnl -$3,52 juta, peringkat sebenarnya +$11,4 juta, tanda terbalik

gmanas: jumlah cashPnl -$2,64 juta, peringkat sebenarnya +$5,02 juta, tanda terbalik

Dari tiga alamat ini, dua tanda keuntungan dan kerugian langsung terbalik.

Penyebabnya: API /positions mengembalikan cashPnl yang tidak mencakup realized PnL yang sudah ditutup/ditebus. Posisi yang menang secara otomatis ditebus menjadi USDC, sehingga posisi itu hilang dari respons API. Yang tersisa adalah posisi yang belum diselesaikan—biasanya dengan kerugian floating.

Kamu pikir sedang menghitung seluruh keuntungan dan kerugian, padahal hanya mendapatkan bagian yang belum diselesaikan.

Lubang 2: bidang makerPnl tidak sesuai dengan aliran kas di chain

Data trading dalam format JSONL memiliki bidang makerPnl (keuntungan dan kerugian maker), yang namanya seolah-olah digunakan untuk menghitung PnL. Tapi jangan percaya.

Saya mengamati data market-making, dan jumlah total makerPnl yang dihitung dari sana berbeda satu tingkat dengan hasil perhitungan aliran kas di chain. Faktor pengali spesifik bisa berbeda tergantung skenario, tapi arah perbedaannya konsisten: logika internal makerPnl tidak cocok dengan aliran USDC yang sebenarnya.

Tidak peduli seberapa besar deviasinya, kesimpulannya sama: jangan gunakan bidang ini untuk menghitung PnL.

Lubang 3: Tidak bisa menghapus duplikasi berdasarkan txHash saja

Ini yang paling kontra intuitif.

Jika satu txHash (hash transaksi) muncul beberapa kali, reaksi pertama yang umum: data duplikat, hapus duplikasi.

Tapi jangan lakukan itu. CLOB (order book on-chain) di Polymarket bisa melakukan matching beberapa order maker dalam satu transaksi chain. Beberapa record dengan txHash yang sama adalah fill yang benar-benar terpisah.

Saya sebelumnya menghapus duplikasi berdasarkan txHash + asset, dan hasilnya kurang sebesar $133 pada sisi BUY. Setelah diverifikasi di Polygon, memang ada beberapa event transfer USDC yang terpisah dalam satu hash transaksi, dan setiap event mewakili transaksi nyata.

Kesimpulan: jangan hapus duplikasi hanya berdasarkan txHash. Untuk menghitung PnL, jumlahkan langsung data mentah dari /activity.

Lubang 4: pagination offset memiliki batasan

Pagination API /activity, pakai offset? Kalau lebih dari 3000, langsung error 400. Tidak ada penjelasan di dokumentasi.

Ketiga alamat di atas sudah diverifikasi: GET /activity?offset=3100 mengembalikan HTTP 400, pesan error: max historical activity offset of 3000 exceeded. Trader besar bisa memiliki puluhan ribu transaksi, 3000 jelas tidak cukup.

Menggunakan parameter end (timestamp dari entri terakhir halaman sebelumnya - 1) sebagai cursor untuk pagination tidak memiliki batasan.

Lubang 5: Perbedaan definisi PnL di peringkat

Setelah menghitung PnL satu alamat, bandingkan dengan peringkat, dan ada selisih sedikit.

Kebanyakan kasus, selisihnya di bawah $10 (karena fluktuasi nilai posisi secara real-time). Tapi jika perbedaannya jauh lebih besar, kemungkinan penyebabnya termasuk: jendela agregasi peringkat, delay pembaruan cache, atau pengguna mengikat beberapa proxy wallet.

Dalam pengujian, metode aliran kas yang dihitung dari data langsung sangat cocok dengan API lb-api. Jika hasilmu berbeda jauh, periksa dulu apakah pagination lengkap (lubang 4), dan apakah menggunakan bidang yang salah (lubang 1-2).

Cara yang benar

Setelah mencoba berbagai metode, saya verifikasi bahwa cara paling andal adalah menggunakan Data API untuk totalisasi aliran kas. Tidak perlu bidang pre-calculated apa pun, cukup hitung dari catatan transaksi asli.

Rumus:

PnL = SUM(TRADE dimana side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE dimana side=BUY) - SUM(SPLIT) + nilai pasar posisi

· TRADE BUY: membeli token dengan USDC (pengeluaran)

· TRADE SELL: menjual token dan mendapatkan USDC kembali (pendapatan)

· REDEEM: menebus posisi yang menang untuk USDC (pendapatan)

· SPLIT: USDC dicetak menjadi token (pengeluaran)

· MERGE: token digabung kembali menjadi USDC (pendapatan)

· MAKER_REBATE: rebate dari maker (pendapatan)

· REWARD: hadiah/airdrop (pendapatan)

· Sumber data:

GET /activity?user=&limit=500, gunakan end untuk pagination, jumlahkan semua berdasarkan tipe.

· Nilai pasar posisi:

GET /positions?user=, jumlah posisi × harga saat ini.

· Validasi silang:

Bandingkan hasil perhitungan dengan API peringkat Polymarket (lb-api.polymarket.com/profit?window=all&address=X), dan jika selisih < $10, dianggap valid. Selisih biasanya karena fluktuasi nilai posisi secara real-time.

Pengujian: peringkat 15 teratas

Setelah menghitung dengan metode aliran kas, lakukan cross-check dengan API peringkat:

swisstony: metode aliran kas +$5,601,000, peringkat +$5,601,000, selisih < $10

kch123: metode aliran kas +$11,396,000, peringkat +$11,396,000, selisih < $10

gmanas: metode aliran kas +$5,024,000, peringkat +$5,024,000, selisih < $10

Ketiga alamat ini memiliki selisih di bawah $10, dan perbedaan berasal dari fluktuasi nilai posisi secara real-time.

Setelah metode ini terbukti, saya gunakan untuk menganalisis ratusan alamat top untuk keuntungan dan kerugian nyata mereka. Itu cerita lain lagi.

Ringkasan

SUM(cashPnl) dari /positions → Tidak bisa, tidak termasuk keuntungan yang sudah diselesaikan, tanda bisa terbalik

Jumlahkan bidang makerPnl → Tidak bisa, tidak sesuai dengan aliran kas di chain

Hapus duplikasi berdasarkan txHash → Tidak bisa, di atas $100, menghapus fill yang nyata

Pagination offset + jumlah → Tidak bisa, data terpotong, >3000 error

Metode Data API aliran kas → Saat ini paling andal, < $10

Langkah pertama untuk quant adalah bukan mencari alpha. Tapi memastikan bahwa perhitunganmu benar.

Semua ini berasal dari pengalaman nyata, bukan teori. API PM bisa berubah kapan saja, disarankan rutin cross-check hasil perhitunganmu dengan API peringkat.