Terakhir kali saya mengisi dana ke exchange, setelah alamat selesai disalin saya juga memeriksa memo dua kali lagi—takut kalau koinnya sudah masuk tapi ternyata tidak bisa dikenali sebagai milik saya. Setelah itu, saya membaca dokumentasi integrasi exchange untuk transaksi dengan @Dusk , dan baru sadar bahwa persyaratan Dusk untuk backend pengisian dana lebih detail daripada sekadar “mengisi memo yang benar”: pertama pilih model akun publik Moonlight, lalu menentukan apakah setiap orang punya akun sendiri, atau memakai akun bersama dengan memo.
Jika menggunakan akun bersama, memo hanya berfungsi untuk memberi tahu sistem “uang ini seharusnya masuk ke siapa”, dan tidak cocok dijadikan satu-satunya bukti untuk mencegah double credit. Dua pengguna bisa saja mengisi memo yang sama dengan salah, dan bahkan satu potong data yang sama bisa dipindai ulang karena backend restart. Dokumentasi resmi karenanya menyarankan memakai ID transaksi Dusk sebagai idempotency key—dengan bahasa sederhana, ini seperti menaruh “kunci yang hanya boleh dicatat sekali” untuk setiap pengisian dana. #dusk
Ada juga batasan yang mudah terlewat: exchange tidak boleh langsung menambah saldo pengguna hanya karena melihat saldo Moonlight bertambah. Exchange perlu memindai dari riwayat arsip yang sudah finalized, transfer langsung, dan menempatkan pengisian yang memo-nya hilang, salah format, tidak dikenal, atau duplikat ke area isolasi—bukan menganggapnya pasti bisa di-credit secara otomatis.
Lebih detail lagi, penulisan catatan pengisian dana ke backend dan pendorongan pemeriksaan (block checking) harus dilakukan dalam transaksi database yang sama. Jika mendorong checkpoint dulu lalu melakukan credit, ketika layanan crash bisa jadi dana pengguna terlewat; jika credit dulu tapi progress tidak tersimpan, saat pemindaian ulang bisa jadi penanganannya dilakukan dua kali. Konversi Phoenix, pembayaran kontrak, dan penarikan staking juga harus masing-masing punya aturan event sendiri—tidak boleh dicampur dengan pengisian dana biasa.
Rangkaian logika ini mirip gudang pengiriman: memo adalah label penerima, transaction ID adalah nomor resi paket yang tidak boleh duplikat, sedangkan finalized adalah saat paket benar-benar masuk ke gudang. Kalau hanya melihat salah satu saja, bisa menyebabkan paket hilang atau pengantaran dobel.
Jadi, ketika saya melihat adaptasi exchange untuk $DUSK , bukan hanya menilai “bisa atau tidak untuk deposit/withdraw”, tetapi juga apakah backend dapat melakukan credit setelah finalized, melakukan deduplikasi transaction ID, menyinkronkan checkpoint dan buku besar dalam submit yang sama. Pengalaman kelas finansial yang sebenarnya bukan putaran cepat di tampilan depan, melainkan meski backend restart atau pemindaian ulang terjadi, jumlah uang yang diterima pengguna tidak jadi lebih atau kurang. #dusk
Jika menggunakan akun bersama, memo hanya berfungsi untuk memberi tahu sistem “uang ini seharusnya masuk ke siapa”, dan tidak cocok dijadikan satu-satunya bukti untuk mencegah double credit. Dua pengguna bisa saja mengisi memo yang sama dengan salah, dan bahkan satu potong data yang sama bisa dipindai ulang karena backend restart. Dokumentasi resmi karenanya menyarankan memakai ID transaksi Dusk sebagai idempotency key—dengan bahasa sederhana, ini seperti menaruh “kunci yang hanya boleh dicatat sekali” untuk setiap pengisian dana. #dusk
Ada juga batasan yang mudah terlewat: exchange tidak boleh langsung menambah saldo pengguna hanya karena melihat saldo Moonlight bertambah. Exchange perlu memindai dari riwayat arsip yang sudah finalized, transfer langsung, dan menempatkan pengisian yang memo-nya hilang, salah format, tidak dikenal, atau duplikat ke area isolasi—bukan menganggapnya pasti bisa di-credit secara otomatis.
Lebih detail lagi, penulisan catatan pengisian dana ke backend dan pendorongan pemeriksaan (block checking) harus dilakukan dalam transaksi database yang sama. Jika mendorong checkpoint dulu lalu melakukan credit, ketika layanan crash bisa jadi dana pengguna terlewat; jika credit dulu tapi progress tidak tersimpan, saat pemindaian ulang bisa jadi penanganannya dilakukan dua kali. Konversi Phoenix, pembayaran kontrak, dan penarikan staking juga harus masing-masing punya aturan event sendiri—tidak boleh dicampur dengan pengisian dana biasa.
Rangkaian logika ini mirip gudang pengiriman: memo adalah label penerima, transaction ID adalah nomor resi paket yang tidak boleh duplikat, sedangkan finalized adalah saat paket benar-benar masuk ke gudang. Kalau hanya melihat salah satu saja, bisa menyebabkan paket hilang atau pengantaran dobel.
Jadi, ketika saya melihat adaptasi exchange untuk $DUSK , bukan hanya menilai “bisa atau tidak untuk deposit/withdraw”, tetapi juga apakah backend dapat melakukan credit setelah finalized, melakukan deduplikasi transaction ID, menyinkronkan checkpoint dan buku besar dalam submit yang sama. Pengalaman kelas finansial yang sebenarnya bukan putaran cepat di tampilan depan, melainkan meski backend restart atau pemindaian ulang terjadi, jumlah uang yang diterima pengguna tidak jadi lebih atau kurang. #dusk
