Tôi cứ nhìn chằm chằm vào sơ đồ luồng thanh toán cổ tức cho đến khi nó bắt đầu không còn “có nghĩa” nữa. DTC → broker → sub-custodian → shareholder (4 chặng), và tôi cho rằng điểm nghẽn nằm ở tốc độ xử lý. Không phải vậy. Càng đào sâu, tôi càng thấy chi phí thực sự nằm ở khâu đối soát: mỗi mắt xích trong chuỗi tự cập nhật hồ sơ của mình độc lập, rồi tất cả mới so sánh ghi chú với nhau sau đó. Đó chính là nơi mà 58B USD mỗi năm chi phí cho các hoạt động doanh nghiệp (corporate action) thực sự “đổ” vào.

Điều khiến tôi chú ý khi tìm hiểu thiết kế XSC của DUSK là nó không cố gắng làm cho từng chặng chạy nhanh hơn. Nó loại bỏ hoàn toàn nhu cầu phải đối soát giữa các chặng. Một lần thực thi, một kết quả: mọi người nắm giữ đều đọc từ cùng một nguồn thay vì bốn bên tự tính riêng rồi sau đó mới đối chiếu kiểm tra lẫn nhau. Đây là lúc cách tiếp cận của DUSK bắt đầu trông khác biệt so với phần lớn hạ tầng mà trước đó tôi từng xem.

Chính khi đó sự phân biệt giữa token hóa và bản địa (native) mới “khớp” với tôi. Việc bọc một cổ phiếu trong token vẫn nằm trên lớp “hạ tầng DTC” tương tự mà bạn chỉ thêm một lớp nữa chứ không thay thế. Phát hành bản địa trên một thứ như DUSK lại đặt một câu hỏi thẳng hơn: liệu bạn còn cần hàng nghìn paying agents (tác nhân chi trả) xử lý độc lập cùng một sự kiện cổ tức nếu đã có một lớp settlement duy nhất mà ai cũng đọc từ đó hay không? Toàn bộ kiến trúc của DUSK dường như đặt cược rằng câu trả lời là “không”.

Tuy vậy, tôi vẫn vướng ở phần trách nhiệm/khả năng chịu rủi ro (liability). Nếu hợp đồng DUSK tính toán sai khoản chi trả, thì ai phải gánh trách nhiệm—chuỗi, tổ chức phát hành (issuer), hay paying agent vốn dĩ từng tồn tại? Tôi nghĩ câu hỏi đó vẫn chưa được trả lời, và tôi cũng không chắc có nên xem nhẹ chỉ vì kiến trúc “gọn gàng” hơn hay không.

#dusk $DUSK @Dusk