#dusk $DUSK @Dusk Saya dulu saat membuat pembayaran di rantai (on-chain) terbiasa menyisipkan nomor pesanan begitu saja ke dalam memo. Namun setelah membaca dokumentasi Transaction Lifecycle untuk @Dusk , saya baru sadar kebiasaan itu tidak bisa begitu saja dipindahkan, karena data transaksi Dusk memiliki relasi pilihan tunggal (single-choice) antara memo, pemanggilan kontrak, deployment kontrak, dan blob. Memo tidak bisa secara default ikut dibawa bersama payload lainnya. Perbedaan ini secara langsung mengubah cara sistem pembayaran “diikat” (dirangkai). Jika merchant ingin menerima pembayaran sekaligus melakukan aksi kontrak, mereka tidak bisa sekadar mengasumsikan bahwa nomor pesanan bisa terus diletakkan di memo dalam transaksi yang sama. Klien perlu lebih dulu menentukan tugas utama transaksi tersebut, lalu merancang pencatatan lain yang andal untuk mengaitkan pesanan. Skenario tekanan (pressure) sebenarnya sangat spesifik: ketika pengguna mengirim pembayaran yang menyertakan aksi kontrak, tampilan front-end menampilkan “sudah terkirim”, tetapi backend mencocokkan pesanan berdasarkan memo. Akibatnya, nominal masuk, namun nomor pesanan tidak muncul seperti yang diharapkan; tim layanan pelanggan akhirnya harus menelusuri transaksi secara manual. Ini mungkin bukan berarti Dusk kehilangan data—lebih mungkin pihak yang melakukan integrasi memaksakan kebiasaan transaksi dari chain lain ke Dusk. Jadi, saat saya melihat integrasi pembayaran DUSK, saya tidak hanya bertanya apakah transfer bisa berhasil. Saya akan memastikan dulu apakah transaksi memang membawa memo atau pemanggilan kontrak, lalu memeriksa apakah keterkaitan pesanan bisa direkonsiliasi secara independen. @Dusk sudah menuliskan dengan jelas batas (payload boundary) tersebut, tetapi apakah contoh-contohnya bisa membuat developer sejak awal menghindari penyalahgunaan semacam ini—itulah yang lebih layak diverifikasi saat Dusk masuk ke skenario pembayaran dunia nyata.