Pengembangan Codex oleh manusia masih kurang dari 1%!
Kemarin baru saja mendapatkan API, lalu saya habiskan sedikit waktu untuk membuat skrip order gantung
Total aset awal akun 311,8u
Jalankan semalaman menghasilkan volume transaksi 8k dan untung 1,31u
Biaya poin seperti ini malah jadi negatif
Keuntungan utamanya karena likuiditas platform sekarang super bagus
Untuk membuat skrip seperti ini, ada banyak hal yang perlu dipikirkan:
- Tugas mana yang bisa dijalankan paralel, dan tindakan mana yang harus berurutan (serial)?
Pembacaan bisa paralel, tapi pengiriman order dan pembatalan order sebaiknya serial. Kalau tidak, mudah terjadi situasi baru saja order dikirim lalu oleh thread lain dihapus salah, dibatalkan salah, atau dipasang ulang berkali-kali
- Apakah BUY dan SELL perlu dipisah ke thread berbeda?
BUY perlu memindai pasar dan order book, jadi lebih lambat; SELL perlu memantau posisi akun, respon harus cepat. Dengan dipisah, proses SELL tidak akan tertahan karena pemindaian penuh yang dilakukan BUY
- Bagaimana merancang local state?
Jangan hanya mengandalkan API open orders, karena keadaan bursa tidak selalu konsisten secara real-time. Setelah create order berhasil, open orders mungkin baru bisa terlihat beberapa detik kemudian. Local state perlu berperan untuk duplikasi jangka pendek, mencegah pengiriman berulang, dan mencegah pembersihan yang salah
- Bagaimana menangani eventual consistency?
Order yang baru dibuat tidak boleh langsung dianggap gagal hanya karena beberapa detik berikutnya open orders belum bisa ditemukan. Perlu ada jendela tunggu, misalnya 30–60 detik, agar thread sinkronisasi akun tidak keliru menghapus order baru
- Bagaimana mengambil harga order?
Ya / Tidak, Over / Under, dan sejenisnya outcome yang saling berlawanan sangat mudah untuk dihitung salah. Terutama saat SELL, sebaiknya gunakan bestAsk dari outcome posisi yang sedang dimiliki, bukan asal mengambil orderbook sisi Yes lalu di-komplement
- Bagaimana menangani presisi kuantitas (share)?
Tampilan di frontend 17,86 tidak berarti jumlah yang benar-benar bisa dijual adalah 17,86. Jumlah saat menempatkan order harus dipotong ke bawah (truncate), bukan dibulatkan. Kalau dibulatkan bisa muncul insufficient shares
- Bagaimana mengklasifikasikan anomali API?
hash mismatch, saldo tidak cukup, share tidak cukup, koneksi putus di sisi remote, respons terpotong, keterlambatan sinkronisasi order—penanganannya berbeda-beda. Tidak boleh sekadar mencoba tanpa batas (infinite retry)
- Bagaimana menulis batasan risk control?
Jangan gunakan market sell, jangan ambil (taker), post-only, batasi rentang BUY, dan batalin buy order sebelum pertandingan dimulai—semua harus menjadi constraint keras (hard constraint) di dalam kode
Bukan berarti karena ada AI, lalu bisa seenaknya membuat sistem yang bisa stabil dalam jangka panjang dan bisa diserahkan (di-deliver) dengan konsisten. Tetap harus fokus dari sisi engineering: lakukan pengujian stabilitas dan risk control
Buat teman-teman yang tertarik, mari saling berdiskusi～
@Predictdotfun
Kemarin baru saja mendapatkan API, lalu saya habiskan sedikit waktu untuk membuat skrip order gantung
Total aset awal akun 311,8u
Jalankan semalaman menghasilkan volume transaksi 8k dan untung 1,31u
Biaya poin seperti ini malah jadi negatif
Keuntungan utamanya karena likuiditas platform sekarang super bagus
Untuk membuat skrip seperti ini, ada banyak hal yang perlu dipikirkan:
- Tugas mana yang bisa dijalankan paralel, dan tindakan mana yang harus berurutan (serial)?
Pembacaan bisa paralel, tapi pengiriman order dan pembatalan order sebaiknya serial. Kalau tidak, mudah terjadi situasi baru saja order dikirim lalu oleh thread lain dihapus salah, dibatalkan salah, atau dipasang ulang berkali-kali
- Apakah BUY dan SELL perlu dipisah ke thread berbeda?
BUY perlu memindai pasar dan order book, jadi lebih lambat; SELL perlu memantau posisi akun, respon harus cepat. Dengan dipisah, proses SELL tidak akan tertahan karena pemindaian penuh yang dilakukan BUY
- Bagaimana merancang local state?
Jangan hanya mengandalkan API open orders, karena keadaan bursa tidak selalu konsisten secara real-time. Setelah create order berhasil, open orders mungkin baru bisa terlihat beberapa detik kemudian. Local state perlu berperan untuk duplikasi jangka pendek, mencegah pengiriman berulang, dan mencegah pembersihan yang salah
- Bagaimana menangani eventual consistency?
Order yang baru dibuat tidak boleh langsung dianggap gagal hanya karena beberapa detik berikutnya open orders belum bisa ditemukan. Perlu ada jendela tunggu, misalnya 30–60 detik, agar thread sinkronisasi akun tidak keliru menghapus order baru
- Bagaimana mengambil harga order?
Ya / Tidak, Over / Under, dan sejenisnya outcome yang saling berlawanan sangat mudah untuk dihitung salah. Terutama saat SELL, sebaiknya gunakan bestAsk dari outcome posisi yang sedang dimiliki, bukan asal mengambil orderbook sisi Yes lalu di-komplement
- Bagaimana menangani presisi kuantitas (share)?
Tampilan di frontend 17,86 tidak berarti jumlah yang benar-benar bisa dijual adalah 17,86. Jumlah saat menempatkan order harus dipotong ke bawah (truncate), bukan dibulatkan. Kalau dibulatkan bisa muncul insufficient shares
- Bagaimana mengklasifikasikan anomali API?
hash mismatch, saldo tidak cukup, share tidak cukup, koneksi putus di sisi remote, respons terpotong, keterlambatan sinkronisasi order—penanganannya berbeda-beda. Tidak boleh sekadar mencoba tanpa batas (infinite retry)
- Bagaimana menulis batasan risk control?
Jangan gunakan market sell, jangan ambil (taker), post-only, batasi rentang BUY, dan batalin buy order sebelum pertandingan dimulai—semua harus menjadi constraint keras (hard constraint) di dalam kode
Bukan berarti karena ada AI, lalu bisa seenaknya membuat sistem yang bisa stabil dalam jangka panjang dan bisa diserahkan (di-deliver) dengan konsisten. Tetap harus fokus dari sisi engineering: lakukan pengujian stabilitas dan risk control
Buat teman-teman yang tertarik, mari saling berdiskusi～
@Predictdotfun
