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

Saya telah mengembangkan otomatisasi perdagangan 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 rugi $3,5 juta, padahal keuntungan sebenarnya $11,4 juta. Bukan selisih beberapa poin persentase—tanda keuntungan dan kerugian bahkan terbalik.

Artikel ini akan membahas setiap lubang yang pernah saya pijak satu per satu. Bagi yang melakukan trading, menulis alat, atau melihat peringkat, pasti akan menemukannya.

Lubang 1: cashPnl Tidak Termasuk Keuntungan yang Sudah Diselesaikan

Pendekatan paling intuitif: tarik /positions, 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 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 semua keuntungan dan kerugian, padahal hanya mendapatkan 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.

Dalam data market-making, saya amati bahwa jumlah dari makerPnl (SUM(makerPnl)) yang dihitung berbeda satu tingkat dari hasil perhitungan arus kas di blockchain. Faktor pengali spesifik bisa berbeda tergantung skenario, tapi arah perbedaannya konsisten: logika internal makerPnl tidak cocok dengan arus 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 txHash yang sama adalah fill yang benar-benar terpisah.

Saya sebelumnya menghapus duplikasi berdasarkan txHash + asset, dan kekurangan di sisi BUY adalah $133. Di Polygon, saya verifikasi bahwa satu hash transaksi memang memiliki beberapa event transfer USDC yang terpisah, masing-masing mewakili transaksi nyata.

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

Lubang 4: Batasan Pagination Offset

Pagination API /activity menggunakan offset? 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. Pemain utama bisa memiliki puluhan ribu transaksi, 3000 saja tidak cukup.

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

Lubang 5: Perbedaan Definisi PnL di Peringkat

Setelah menghitung PnL satu alamat, bandingkan dengan API peringkat, dan 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 penggabungan peringkat, penundaan pembaruan cache, atau pengguna mengikat beberapa proxy wallet.

Dalam pengujian, PnL yang dihitung dengan metode arus kas sangat cocok dengan nilai yang dikembalikan oleh 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 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 pasar posisi

· TRADE BUY: Membeli token dengan USDC (pengeluaran)

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