Saya terus menatap bagan alur pembayaran dividen sampai akhirnya tidak masuk akal lagi. DTC ke broker ke sub-kustodian ke pemegang saham—empat hop—dan saya mengira hambatannya ada di kecepatan pemrosesan. Ternyata bukan. Semakin saya memeriksanya, biaya sebenarnya ada pada rekonsiliasi: setiap mata rantai di rantai itu memperbarui catatannya sendiri secara independen, lalu semua pihak membandingkan catatan setelahnya. Di sanalah biaya aksi korporasi sebesar $58B per tahun benar-benar mengalir.
Yang menonjol saat saya menelusuri desain XSC DUSK adalah bahwa ia tidak berusaha membuat setiap hop menjadi lebih cepat. Ia menghilangkan kebutuhan agar hop-hop itu perlu melakukan rekonsiliasi sama sekali: satu eksekusi, satu hasil, setiap pemegang membaca dari sumber yang sama, bukan empat pihak yang menghitung terpisah lalu saling mencocokkan belakangan. Di sinilah pendekatan DUSK mulai terasa berbeda dari kebanyakan infrastruktur yang sebelumnya pernah saya lihat.
Saat itulah perbedaan tokenisasi vs native akhirnya “klik” untuk saya. Membungkus sebuah saham dalam token tetap berada di atas infrastruktur DTC yang sama—Anda menambah lapisan, bukan menggantinya. Native issuance pada sesuatu seperti DUSK mengajukan pertanyaan yang lebih tegas: apakah Anda masih perlu ribuan paying agent yang memproses secara independen kejadian dividen yang sama, jika ada satu lapisan settlement yang dibaca oleh semua orang? Seluruh arsitektur DUSK tampaknya bertaruh pada jawaban “tidak”.
Namun saya masih mentok pada bagian liabilitas. Jika kontrak DUSK salah menghitung pembayaran, siapa yang akan bertanggung jawab—rantai, penerbit, atau paying agent yang sebelumnya ada? Saya tidak yakin itu sudah dijawab, dan saya juga tidak yakin itu seharusnya dibiarkan begitu saja hanya karena arsitekturnya terlihat lebih bersih.
#dusk $DUSK @Dusk
Yang menonjol saat saya menelusuri desain XSC DUSK adalah bahwa ia tidak berusaha membuat setiap hop menjadi lebih cepat. Ia menghilangkan kebutuhan agar hop-hop itu perlu melakukan rekonsiliasi sama sekali: satu eksekusi, satu hasil, setiap pemegang membaca dari sumber yang sama, bukan empat pihak yang menghitung terpisah lalu saling mencocokkan belakangan. Di sinilah pendekatan DUSK mulai terasa berbeda dari kebanyakan infrastruktur yang sebelumnya pernah saya lihat.
Saat itulah perbedaan tokenisasi vs native akhirnya “klik” untuk saya. Membungkus sebuah saham dalam token tetap berada di atas infrastruktur DTC yang sama—Anda menambah lapisan, bukan menggantinya. Native issuance pada sesuatu seperti DUSK mengajukan pertanyaan yang lebih tegas: apakah Anda masih perlu ribuan paying agent yang memproses secara independen kejadian dividen yang sama, jika ada satu lapisan settlement yang dibaca oleh semua orang? Seluruh arsitektur DUSK tampaknya bertaruh pada jawaban “tidak”.
Namun saya masih mentok pada bagian liabilitas. Jika kontrak DUSK salah menghitung pembayaran, siapa yang akan bertanggung jawab—rantai, penerbit, atau paying agent yang sebelumnya ada? Saya tidak yakin itu sudah dijawab, dan saya juga tidak yakin itu seharusnya dibiarkan begitu saja hanya karena arsitekturnya terlihat lebih bersih.
#dusk $DUSK @Dusk
