Skip to main content
Saat Anda mengirim order, chain menetapkan order ID untuknya. ID itu otoritatif, tetapi Anda baru mengetahuinya setelah order diterima — dan itu masalah kalau yang perlu Anda lakukan justru membatalkan order yang penerimaannya tidak pernah Anda lihat. Client order ID menyelesaikan itu. Anda membuat sendiri identifier-nya, melampirkannya saat pengiriman, dan bisa bertindak atas order itu memakai identifier tersebut sejak detik Anda mengirimnya.

​
Mengapa ini lebih penting daripada kedengarannya

Bayangkan pengiriman order yang timeout. Apakah order itu sampai ke chain? Anda tidak tahu. Tanpa client order ID, pilihan Anda adalah mengueri order terakhir lalu menebak berdasarkan pasar, sisi, harga, dan kuantitas — atau tidak melakukan apa-apa dan berharap. Dengan client order ID, ambiguitasnya lenyap. Anda membatalkan memakai identifier yang Anda buat. Kalau order itu ada, order itu dibatalkan. Kalau tidak pernah sampai, pembatalan itu tidak menemukan apa pun. Bagaimanapun, Anda berakhir pada state yang diketahui — dan itulah yang sebenarnya dibutuhkan sistem yang berjalan tanpa diawasi manusia. Ini juga yang membuat rekonsiliasi bisa dikerjakan. Catatan Anda sendiri memakai identifier yang Anda tetapkan sebagai kunci, jadi mencocokkan pandangan Anda dengan pandangan chain adalah pencarian nilai, bukan tebakan heuristik.

​
Format

Identifier-nya adalah nilai 16 byte, dikirim sebagai string heksadesimal huruf kecil berawalan 0x sepanjang 32 karakter.
Tiga aturan yang ditegakkan protokol:
  • Hanya huruf kecil. Heksadesimal huruf besar ditolak, bukan dinormalkan.
  • Panjang harus persis. Nilai yang lebih pendek atau lebih panjang ditolak.
  • Nilai nol seluruhnya dicadangkan. 0x00000000...0000 adalah penanda sentinel yang berarti tidak ada, dan tidak bisa dipakai sebagai identifier.
Field ini opsional. Order tanpa client order ID berperilaku normal dalam segala hal — order semacam itu hanya tidak bisa dibatalkan lewat client order ID, melainkan lewat order ID yang ditetapkan chain.

​
Keunikan

Keunikan berlaku dalam lingkup subakun: kombinasi alamat penanda tangan dan subakun di bawahnya. Ada dua konsekuensinya. Subakun berbeda di bawah alamat yang sama boleh memakai identifier yang sama tanpa konflik — berguna saat menjalankan strategi independen yang masing-masing membuat ID sendiri. Dan di dalam satu subakun, memakai ulang identifier yang sedang dipegang order aktif adalah error, bukan penggantian.
Buat identifier secara acak, bukan berurutan. Penghitung memang menggoda karena membuat urutan terlihat, tetapi restart yang menghilangkan penghitung menghasilkan tabrakan dengan order yang masih aktif, sedangkan 16 byte acak praktis tidak pernah bertabrakan.

​
Apa yang bisa Anda lakukan dengannya

​
Masa hidup

Identifier itu milik order, bukan milik sesi Anda. Nilainya tetap bisa dikueri setelah order tereksekusi atau dibatalkan, dan itulah yang membuatnya berguna untuk rekonsiliasi setelah kejadian. Identifier bisa dipakai ulang begitu order yang ditandainya tidak lagi aktif. Dalam praktik hampir tidak ada alasan untuk memakai ulang — nilai acak baru tidak memakan biaya apa pun dan menghapus keraguan tentang order mana yang dirujuk catatan historis.

​
Selanjutnya

Mengubah order

Mengubah order aktif, dan apa yang terjadi pada identifier-nya.

Jenis order

Apa saja yang bisa Anda lampiri identifier.

Developer

Mengirim order dan menangani respons yang ambigu di dalam kode.

Pengurutan transaksi

Mengapa pembatalan yang dikirim di blok yang sama berjalan lebih dulu daripada order agresif.