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 bahkan perhitungan berapa banyak uang yang saya hasilkan pun salah.

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

Seberapa jauh deviasinya?
Peringkat ketiga, kch123, dihitung dengan metode yang salah dan kehilangan $3,5 juta, padahal keuntungan sebenarnya adalah $11,4 juta.
Bukan 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.

Lubang 1: cashPnl Tidak Termasuk Keuntungan yang Sudah Diselesaikan

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

Menggunakan tiga alamat teratas dari peringkat untuk pengujian nyata:

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

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

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

Kamu kira sedang menghitung seluruh keuntungan dan kerugian, padahal yang didapat hanyalah bagian yang belum diselesaikan.

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

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

Saya mengamati data market-making, jumlah dari makerPnl yang dihitung dengan SUM(makerPnl) berbeda satu tingkat dari hasil perhitungan arus kas di blockchain.
Jumlah pasti 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 field ini untuk menghitung PnL.

Lubang 3: Tidak Bisa Menggunakan txHash Sendiri untuk Menghapus Duplikasi

Ini yang paling kontra 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) di Polymarket bisa mencocokkan beberapa order maker dalam satu transaksi blockchain, dan beberapa record di bawah satu txHash adalah fill yang benar-benar terpisah.

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

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

Lubang 4: Batasan Pagination Offset

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

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

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

Lubang 5: Perbedaan Kriteria PnL di Peringkat

Setelah menghitung PnL satu alamat, lalu dibandingkan dengan peringkat, ada sedikit perbedaan.

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

Dalam pengujian, PnL satu alamat yang dihitung dengan metode arus kas sangat cocok dengan nilai yang dikembalikan oleh API lb-api.
Jika hasilmu berbeda jauh, periksa dulu apakah proses pagination lengkap (lubang 4), dan 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-calculated apapun, langsung hitung dari catatan transaksi asli untuk masuk dan keluarnya dana.

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 (pendapatan)

· REDEEM: Menebus posisi yang menang dan mendapatkan 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=