Seorang pengembang berbagi bagaimana membangun robot perdagangan Polymarket, dengan menangkap fluktuasi harga pasar BTC selama 15 menit, mengubah $1.000 menjadi $1.869 dalam beberapa hari, dengan tingkat pengembalian (ROI) sebesar 86%. Artikel ini secara rinci memperkenalkan logika pembangunan robot, metode backtest, dan keterbatasannya.
（Latar belakang: Polymarket, pemimpin pasar prediksi, mengumumkan pembangunan L2 sendiri, apakah keunggulan Polygon hilang?）
（Tambahan latar belakang: Bagaimana melakukan arbitrase di Polymarket untuk mencapai hasil tahunan 40%?）

Daftar Isi Artikel

• Logika pembangunan robot
• Backtest
• Keterbatasan backtest
• Infrastruktur

Beberapa minggu yang lalu, saya memutuskan untuk membangun robot Polymarket saya sendiri. Versi lengkapnya memakan waktu beberapa minggu.

Saya bersedia menginvestasikan tenaga ini karena memang ada celah efisiensi di Polymarket, meskipun sudah ada beberapa robot yang memanfaatkan ketidakefisienan ini untuk mendapatkan keuntungan, namun masih jauh dari cukup, peluang di pasar ini jauh lebih banyak daripada jumlah robot yang ada.

Logika pembangunan robot

Logika robot ini didasarkan pada satu set strategi yang pernah saya jalankan secara manual sebelumnya. Untuk meningkatkan efisiensi, saya otomatisasi strategi tersebut. Robot ini berjalan di pasar “BTC 15 menit UP/DOWN” (BTC 15-minute UP/DOWN).

Robot ini menjalankan program pemantauan real-time yang mampu secara otomatis beralih ke putaran BTC 15 menit saat ini, melalui streaming WebSocket mengirimkan harga beli/jual terbaik (best bid/ask), menampilkan UI terminal tetap, dan memungkinkan kontrol lengkap melalui perintah teks.

Dalam mode manual, Anda bisa langsung melakukan order.

buy up / buy down : membeli sejumlah dolar tertentu.

buyshares up / buyshares down : membeli jumlah saham tertentu, menggunakan order LIMIT (batas harga) + GTC (berlaku sampai dibatalkan) yang ramah pengguna, dengan harga jual terbaik (best ask) saat ini.

Dalam mode otomatis, menjalankan siklus dua langkah (two-leg) berulang.

Langkah pertama, robot hanya mengamati fluktuasi harga dalam windowMin menit setelah setiap putaran dimulai. Jika salah satu sisi turun cukup cepat (penurunan minimal dalam sekitar 3 detik mencapai movePct), maka akan memicu “Langkah 1 (Leg 1)”, membeli sisi yang jatuh tajam tersebut.

Setelah menyelesaikan Leg 1, robot tidak akan membeli sisi yang sama lagi. Ia akan menunggu “Langkah 2 (Leg 2, yaitu hedging)”, dan hanya akan memicu jika memenuhi syarat: leg1EntryPrice + oppositeAsk <= sumTarget.

Ketika kondisi ini terpenuhi, robot membeli sisi yang berlawanan. Setelah Leg 2 selesai, siklus ini berakhir, robot kembali ke status pengamatan, menunggu sinyal jatuh tajam berikutnya dengan parameter yang sama.

Jika selama siklus terjadi perubahan putaran, robot akan membatalkan siklus tersebut dan memulai lagi dengan pengaturan yang sama di putaran berikutnya.

Parameter mode otomatis sebagai berikut: auto on [sum=0.95] [move=0.15] [windowMin=2]

• shares: ukuran posisi untuk kedua langkah transaksi.
• sum: ambang batas hedging.
• move (movePct): ambang penurunan (misalnya 0.15 = 15%).
• windowMin: durasi dalam menit dari awal setiap putaran untuk melakukan Leg 1.

Backtest

Logika robot sangat sederhana: menunggu penurunan tajam, membeli sisi yang baru saja jatuh, lalu menunggu harga stabil dan melakukan hedging dengan membeli sisi berlawanan, sambil memastikan: priceUP + priceDOWN < 1.

Namun, logika ini perlu diuji. Apakah benar efektif dalam jangka panjang? Yang lebih penting, robot memiliki banyak parameter (jumlah saham, total, persentase pergerakan, durasi window, dll). Kombinasi parameter mana yang paling optimal dan memaksimalkan keuntungan?

Ide pertama saya adalah menjalankan robot secara live selama seminggu dan mengamati hasilnya. Masalahnya, ini memakan waktu lama dan hanya bisa menguji satu set parameter sekaligus, sementara saya perlu menguji banyak set.

Ide kedua saya adalah menggunakan data historis online dari Polymarket CLOB API untuk melakukan backtest. Sayangnya, untuk pasar BTC 15 menit UP/DOWN, endpoint data historis selalu mengembalikan dataset kosong. Tidak ada data harga historis (ticks), sehingga backtest tidak bisa mendeteksi “penurunan tajam dalam sekitar 3 detik”, dan tidak akan memicu Leg 1, apapun parameter yang digunakan, menghasilkan 0 siklus dan ROI 0%.

Setelah penyelidikan lebih lanjut, saya menemukan bahwa pengguna lain juga mengalami masalah yang sama saat mengakses data historis dari beberapa pasar tertentu. Saya mencoba pasar lain yang memang mengembalikan data historis, dan menyimpulkan: untuk pasar ini, data historis sama sekali tidak disimpan.

Karena batasan ini, satu-satunya cara yang dapat diandalkan untuk melakukan backtest strategi ini adalah dengan merekam data harga terbaik secara real-time saat robot berjalan, dan membangun dataset historis saya sendiri.

Perekam ini menyimpan snapshot ke disk yang berisi:

• timestamp
• round slug
• sisa detik
• ID token UP/DOWN
• harga jual terbaik (best ask)

Selanjutnya, “recorded backtest” akan memutar ulang snapshot ini dan secara deterministik menerapkan logika otomatis yang sama. Ini memastikan data frekuensi tinggi yang diperlukan untuk mendeteksi penurunan tajam dan kondisi hedging.

Dalam 4 hari, saya mengumpulkan sekitar 6 GB data. Saya bisa merekam lebih banyak, tetapi saya rasa ini cukup untuk menguji berbagai kombinasi parameter.

Saya mulai menguji parameter ini:

• saldo awal: $1.000
• setiap transaksi: 20 saham
• sumTarget = 0.95
• ambang penurunan = 15%
• windowMin = 2 menit

Saya juga menerapkan biaya tetap 0.5% dan spread 2% untuk menjaga skenario konservatif.

Hasil backtest menunjukkan ROI sebesar 86%, dalam beberapa hari saja, uang $1.000 menjadi $1.869.

Kemudian saya uji dengan parameter yang lebih agresif:

• saldo awal: $1.000
• setiap transaksi: 20 saham
• sumTarget = 0.6
• ambang penurunan = 1%
• windowMin = 15 menit

Hasilnya: setelah 2 hari, ROI -50%.

Ini dengan jelas menunjukkan bahwa pemilihan parameter sangat penting. Parameter bisa membuat Anda sangat untung, atau mengalami kerugian besar.

Keterbatasan backtest

Bahkan dengan memperhitungkan biaya dan spread, backtest tetap memiliki keterbatasan.

• Pertama, data hanya beberapa hari, mungkin tidak cukup untuk gambaran pasar yang lengkap.
• Ia bergantung pada snapshot harga jual terbaik yang direkam; dalam kenyataannya, order bisa terisi sebagian, atau terisi dengan harga berbeda. Selain itu, kedalaman order book dan volume yang tersedia tidak dimodelkan.
• Tidak menangkap fluktuasi mikro di bawah detik (data diambil setiap detik). Meski timestamp satu detik, banyak hal bisa terjadi di antara detik-detik tersebut.
• Dalam backtest, slippage diasumsikan konstan, tanpa simulasi delay variabel (misalnya 200–1500 ms) atau lonjakan jaringan.
• Setiap transaksi dianggap “eksekusi instan” (tanpa antrean order, tanpa order limit).
• Biaya diasumsikan tetap, padahal dalam kenyataannya tergantung pada: pasar/token, pembuat/maker taker, level biaya, kondisi, dll.

Untuk bersikap konservatif, saya menerapkan aturan: jika Leg 2 tidak terisi sebelum pasar tutup, maka Leg 1 dianggap total loss.

Ini sangat konservatif, tetapi tidak selalu sesuai kenyataan:

• Kadang Leg 1 bisa ditutup lebih awal,
• Kadang akhirnya ITM dan menang,
• Kadang kerugian bisa sebagian, bukan seluruhnya.

Meskipun kerugian ini mungkin berlebihan, ini memberi gambaran skenario terburuk yang praktis.

Yang terpenting, backtest tidak bisa mensimulasikan dampak order besar terhadap order book atau menarik trader lain untuk ikut berperang. Dalam kenyataan, order Anda bisa:

• Mengganggu order book,
• Menarik atau menolak trader lain,
• Menimbulkan slippage nonlinier.

Backtest mengasumsikan Anda adalah pelaku likuiditas murni (price taker), tanpa pengaruh apapun.

Akhirnya, tidak mensimulasikan batas frekuensi (rate limits), error API, order ditolak, suspend, timeout, reconnect, atau robot yang sibuk dan melewatkan sinyal.

Backtest sangat berharga untuk mengidentifikasi rentang parameter yang baik, tetapi bukan jaminan 100%, karena beberapa efek dunia nyata tidak bisa dimodelkan.

Infrastruktur

Saya berencana menjalankan robot ini di Raspberry Pi, agar tidak membebani resource komputer utama saya, dan bisa berjalan 24/7.

Namun, ini masih bisa ditingkatkan secara signifikan:

• Menggunakan Rust alih-alih JavaScript akan jauh meningkatkan performa dan waktu respons.
• Menjalankan node RPC Polygon khusus akan mengurangi latensi lebih jauh.
• Menempatkan VPS dekat server Polymarket juga akan mengurangi latensi secara signifikan.

Tentu masih ada optimasi lain yang belum saya temukan. Saat ini, saya sedang belajar Rust karena bahasa ini semakin menjadi bahasa penting dalam pengembangan Web3.

#####