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, dan situs analisis pihak ketiga yang menampilkan peringkat 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 hanya 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 menemukannya.

Lubang 1: cashPnl Tidak Termasuk Keuntungan yang Sudah Diselesaikan

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

Uji coba langsung tiga alamat teratas di peringkat:

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

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

Penyebabnya: API /positions yang dikembalikan tidak menyertakan realized PnL yang sudah ditutup/diredeem. Posisi yang menang secara otomatis diredeem menjadi USDC, dan posisi ini hilang dari respons API. Yang tersisa adalah posisi yang belum diselesaikan—sering kali dengan kerugian floating.

Kamu kira 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/kerugian maker), namanya saja sudah menunjukkan untuk menghitung PnL. Tapi jangan percaya.

Saya mengamati data market-making, dan jumlah dari SUM(makerPnl) berbeda satu tingkat dengan hasil perhitungan arus kas di chain.
Jumlah pastinya 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 chain, dan beberapa record di bawah satu txHash adalah fill yang nyata dan independen.

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

Kesimpulan: Tidak bisa hanya berdasarkan txHash untuk menghapus duplikasi. Untuk menghitung PnL, langsung jumlahkan data mentah dari /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 bisa memiliki puluhan ribu transaksi, 3000 saja tidak cukup.

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

Lubang 5: Perbedaan Kriteria PnL di Peringkat

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

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

Dalam pengujian, metode perhitungan arus kas sangat cocok dengan API peringkat lb-api.polymarket.com/profit?window=all&address=X. Jika hasilmu berbeda jauh, periksa dulu apakah 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 apa pun, langsung hitung dari catatan transaksi asli.

Rumus:

PnL = SUM(TRADE saat side=SELL) + SUM(REDEEM) + SUM(MERGE) + SUM(MAKER_REBATE) + SUM(REWARD) - SUM(TRADE saat side=BUY) - SUM(SPLIT) + Nilai posisi

· TRADE BUY: Membeli token dengan USDC (pengeluaran)

· TRADE SELL: Menjual token dan mengumpulkan USDC (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=