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

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

Bukan saya yang tidak kompeten. Masalahnya adalah perhitungan PnL di PM sendiri adalah area berbahaya. API resmi yang diberikan angka-angkanya salah, situs analisis pihak ketiga juga menampilkan peringkat yang salah. Kamu menulis skrip sendiri untuk menghitung? Kemungkinan besar tetap salah.

Seberapa jauh 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 pernah saya pijak. Baik yang melakukan trading, menulis alat, maupun yang melihat peringkat, pasti akan menemui ini.

Lubang 1: cashPnl Tidak Termasuk Keuntungan yang Sudah Diselesaikan

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

Mengambil tiga alamat teratas dari peringkat dan mengujinya secara langsung:

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

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

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

Tiga alamat ini, dua di antaranya tanda keuntungan dan kerugian langsung terbalik.

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

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

Lubang 2: Field makerPnl Tidak Konsisten dengan Arus Kas di Chain

Data perdagangan dalam format JSONL memiliki field makerPnl (keuntungan dan kerugian maker), yang namanya menunjukkan itu untuk menghitung PnL. Tapi jangan percaya.

Saya mengamati data market-making, jumlahkan makerPnl dan hasilnya berbeda satu tingkat dengan hasil perhitungan arus kas di chain. Skala pastinya bisa berbeda tergantung skenario, tapi arah perbedaannya konsisten: logika internal makerPnl tidak cocok dengan arus USDC nyata.

Tidak peduli seberapa besar deviasinya, kesimpulannya sama: Jangan gunakan field ini untuk menghitung PnL.

Lubang 3: Tidak Bisa Menggunakan txHash Sendiri untuk Menghapus Duplikasi

Ini yang paling tidak intuitif.

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

Tapi jangan lakukan itu. CLOB (order book on-chain) Polymarket bisa mencocokkan beberapa order maker dalam satu transaksi chain, dan beberapa record di bawah satu txHash adalah fill yang nyata dan independen.

Saya sebelumnya menghapus duplikasi berdasarkan txHash + asset, dan mengurangi $133 dari sisi BUY. Setelah diverifikasi di Polygon chain, memang ada beberapa event transfer USDC yang terpisah dalam satu transaksi hash, masing-masing mewakili transaksi nyata.

Kesimpulan: Tidak bisa hanya menghapus duplikasi berdasarkan txHash. Untuk menghitung PnL, jumlahkan langsung data mentah /activity.

Lubang 4: Batasan dalam Penggunaan offset untuk Paginasi

Paginasi API /activity dengan offset? Jika lebih dari 3000, langsung error 400. Tidak tertulis di dokumentasi.

Tiga alamat di atas sudah diverifikasi: GET /activity?offset=3100 mengembalikan HTTP 400, pesan error “max historical activity offset of 3000 exceeded”. Pemain utama dengan puluhan ribu transaksi, 3000 saja tidak cukup.

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

Lubang 5: Perbedaan Definisi PnL di Peringkat

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

Sebagian besar perbedaan di bawah $10 (berasal dari fluktuasi nilai pasar posisi secara real-time). Tapi jika perbedaan jauh lebih besar, kemungkinan penyebabnya termasuk: jendela agregasi peringkat, penundaan pembaruan cache, atau pengguna yang mengikat beberapa proxy wallet.

Dalam pengujian, PnL satu alamat yang dihitung dengan metode arus kas sangat konsisten dengan nilai yang dikembalikan oleh lb-api. Jika hasilmu berbeda jauh, periksa dulu apakah paginasi lengkap (lubang 4), atau apakah menggunakan field yang salah (lubang 1-2).

Cara yang benar

Setelah mencoba berbagai metode, saya verifikasi bahwa cara paling andal adalah menggunakan Data API untuk merangkum arus kas. Tanpa field pre-kalkulasi apapun, langsung 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: Menggunakan USDC untuk membeli token (pengeluaran)

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

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

· SPLIT: USDC diubah 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=