Beberapa minggu yang lalu, saya memutuskan untuk membangun bot Polymarket saya sendiri. Versi lengkapnya menghabiskan waktu beberapa minggu.
Saya bersedia menginvestasikan usaha ini karena memang ada ketidakefisienan di Polymarket. Meskipun sudah ada beberapa bot yang memanfaatkan ketidakefisienan ini untuk mendapat keuntungan, jumlahnya masih jauh dari cukup. Peluang di pasar ini masih jauh lebih banyak daripada jumlah bot.
Logika Pembuatan Bot
Logika bot ini didasarkan pada strategi yang saya jalankan secara manual sebelumnya. Untuk meningkatkan efisiensi, saya mengotomatiskannya. Bot ini berjalan di pasar "BTC 15 menit NAIK / TURUN (BTC 15-minute UP/DOWN)".
Bot menjalankan program pemantauan real-time yang dapat beralih otomatis ke ronde BTC 15 menit terkini, mentransmisikan harga beli/ jual terbaik (best bid/ask) melalui WebSocket streaming, menampilkan UI terminal yang tetap, dan memungkinkan kontrol penuh melalui perintah teks.
Dalam mode manual, Anda dapat langsung memasukkan pesanan.
buy up
buyshares up
Mode otomatis menjalankan siklus dua tahap (two-leg) yang berulang.
Tahap pertama, ia hanya mengamati fluktuasi harga dalam windowMin menit pertama setelah setiap ronde dimulai. Jika salah satu sisi turun cukup cepat (turun setidaknya movePct dalam sekitar 3 detik), bot akan memicu "Tahap 1 (Leg 1)", membeli sisi yang anjlok tersebut.
Setelah menyelesaikan Leg 1, bot tidak akan pernah membeli sisi yang sama lagi. Ia akan menunggu "Tahap 2 (Leg 2, yaitu lindung nilai)", dan hanya akan memicu jika kondisi berikut terpenuhi: leg1EntryPrice + oppositeAsk <= sumTarget.
Ketika kondisi ini terpenuhi, ia membeli sisi yang berlawanan. Setelah Leg 2 selesai, siklus berakhir, dan bot kembali ke status observasi, menunggu sinyal anjlok berikutnya dengan pengaturan yang sama.
Jika ronde berubah selama siklus berlangsung, bot akan mengabaikan siklus yang terbuka dan memulai kembali dengan pengaturan yang sama di ronde berikutnya.
Parameter untuk mode otomatis diatur sebagai berikut: auto on
· shares: Ukuran posisi yang digunakan untuk kedua tahap transaksi.
· sum: Ambang batas yang diizinkan untuk lindung nilai.
· move (movePct): Ambang batas anjlok (misalnya 0.15 = 15%).
· windowMin: Durasi dari awal setiap ronde yang diizinkan untuk mengeksekusi Leg 1.
Backtest
Logika bot ini sederhana: tunggu penjualan besar-besaran (暴力砸盘), beli sisi yang baru saja turun, lalu tunggu harga stabil dan lindung nilai dengan membeli sisi yang berlawanan, sambil memastikan: priceUP + priceDOWN < 1.
Tapi logika ini perlu diuji. Apakah benar-benar efektif dalam jangka panjang? Yang lebih penting, bot memiliki banyak parameter (jumlah saham, sum, persentase pergerakan, menit jendela, dll.). Set parameter mana yang optimal dan memaksimalkan keuntungan?
Pikiran pertama saya adalah menjalankan bot secara live selama seminggu dan mengamati hasilnya. Masalahnya, ini terlalu memakan waktu dan hanya menguji satu set parameter, sedangkan saya perlu menguji banyak set.
Pikiran kedua saya adalah melakukan backtest menggunakan data historis online dari Polymarket CLOB API. Sayangnya, untuk pasar BTC 15 menit NAIK/TURUN, endpoint data historis terus mengembalikan dataset kosong. Tanpa data history ticks, backtest tidak dapat mendeteksi "anjlok dalam sekitar 3 detik", tidak dapat memicu Leg 1, dan menghasilkan 0 siklus dan 0% ROI (Return on Investment) berapa pun parameternya.
Setelah penyelidikan lebih lanjut, saya menemukan bahwa pengguna lain mengalami masalah yang sama saat mengambil data historis untuk pasar tertentu. Saya menguji pasar lain yang memang mengembalikan data historis dan menyimpulkan bahwa untuk pasar khusus ini, data historis memang tidak disimpan.
Karena keterbatasan ini, satu-satunya cara yang andal untuk melakukan backtest strategi ini adalah dengan membuat dataset historis saya sendiri dengan merekam best-ask secara real-time saat bot berjalan.
Perekam menulis snapshot ke disk, berisi:
· Stempel waktu
· Pengidentifikasi ronde (round slug)
· Detik tersisa
· ID Token UP/DOWN
· Harga jual terbaik (best ask) UP/DOWN
Kemudian, "backtest yang direkam (recorded backtest)" akan memutar ulang snapshot ini dan menerapkan logika otomatis yang sama secara deterministik. Ini menjamin ketersediaan data frekuensi tinggi yang diperlukan untuk mendeteksi anjlok dan kondisi lindung nilai.
Saya mengumpulkan total 6 GB data dalam 4 hari. Saya bisa merekam lebih banyak, tapi saya rasa ini cukup untuk menguji berbagai set parameter.
Saya mulai menguji set parameter ini:
· Saldo awal: $1,000
· 20 saham per transaksi
· sumTarget = 0.95
· Ambang batas anjlok = 15%
· windowMin = 2 menit
Saya juga menerapkan biaya konstan 0.5% dan spread 2% untuk tetap berada dalam skenario konservatif.
Backtest menunjukkan ROI 86%, $1,000 berubah menjadi $1,869 hanya dalam beberapa hari.
Kemudian saya menguji set parameter yang lebih agresif:
· Saldo awal: $1,000
· 20 saham per transaksi
· sumTarget = 0.6
· Ambang batas anjlok = 1%
· windowMin = 15 menit
Hasil: ROI -50% setelah 2 hari.
Ini jelas menunjukkan bahwa pemilihan parameter adalah faktor terpenting. Itu bisa membuat Anda menghasilkan banyak uang, atau menyebabkan kerugian besar.
Keterbatasan Backtest
Bahkan dengan memasukkan biaya dan spread, backtest memiliki keterbatasannya.
· Pertama, backtest hanya menggunakan data beberapa hari, yang mungkin tidak cukup untuk mendapatkan perspektif pasar yang komprehensif.
· Backtest mengandalkan snapshot best-ask yang direkam; dalam kenyataannya, pesanan mungkin terisi sebagian, atau dieksekusi pada harga yang berbeda. Selain itu, kedalaman buku pesanan dan volume yang tersedia tidak dimodelkan.
· Fluktuasi mikro di bawah detik tidak tertangkap (data diambil sampelnya setiap detik). Backtest meskipun memiliki stempel waktu 1 detik, banyak hal bisa terjadi di antara setiap detik.
· Dalam backtest, slippage bersifat konstan, tidak mensimulasikan latency yang variabel (misalnya 200–1500 ms) atau puncak jaringan.
· Setiap transaksi leg dianggap dieksekusi "secara instan" (tidak ada antrian pesanan, tidak ada pesanan tertahan).
· Biaya dibebankan secara seragam, sedangkan dalam kenyataannya biaya mungkin bergantung pada: pasar / token, maker vs taker, tingkat biaya, atau kondisi.
Untuk tetap pesimis (prudent), saya menerapkan aturan: jika Leg 2 gagal dieksekusi sebelum pasar ditutup, Leg 1 akan dianggap sebagai loss total (total loss).
Ini sengaja konservatif, tetapi tidak selalu sesuai dengan kenyataan:
· Terkadang Leg 1 dapat ditutup lebih awal,
· Terkadang akhirnya dalam keadaan in-the-money (ITM) dan menang,
· Terkadang kerugian bisa parsial dan bukan keseluruhan.
Meskipun kerugian mungkin dilebih-lebihkan, ini memberikan skenario "kondisi terburuk" yang praktis.
Yang paling penting, backtest tidak dapat mensimulasikan dampak pesanan besar Anda terhadap buku pesanan atau menarik trader lain untuk memburu Anda. Dalam kenyataannya, pesanan Anda dapat:
· Mengganggu buku pesanan,
· Menarik atau mengusir trader lain,
· Menyebabkan slippage non-linear.
Backtest mengasumsikan Anda adalah pengambil likuiditas (price taker) murni, tanpa pengaruh apa pun.
Terakhir, backtest tidak mensimulasikan batasan frekuensi (rate limits), kesalahan API, pesanan ditolak, ditangguhkan, waktu habis, sambungan ulang, atau bot sibuk dan melewatkan sinyal.
Backtest sangat berharga untuk mengidentifikasi rentang parameter yang baik, tetapi bukan jaminan 100%, karena beberapa efek dunia nyata tidak dapat dimodelkan.
Infrastruktur
Saya berencana menjalankan bot ini di Raspberry Pi untuk menghindari mengonsumsi sumber daya komputer utama saya dan menjaga agar tetap berjalan 24/7.
Tapi ini masih memiliki ruang perbaikan yang signifikan:
· Menggunakan Rust alih-alih JavaScript akan memberikan kinerja dan waktu pemrosesan yang jauh lebih unggul.
· Menjalankan dedicated Polygon RPC node akan lebih mengurangi latency.
· Deploy di VPS yang dekat dengan server Polymarket juga akan secara signifikan mengurangi latency.
Pasti ada metode optimasi lain yang belum saya temukan. Saat ini, saya sedang mempelajari Rust karena bahasa ini menjadi sangat penting dalam pengembangan Web3.
