#dusk $DUSK
Điều thu hút sự chú ý của tôi không phải là con số 300 triệu euro gắn với NPEX — mà là một chi tiết nhỏ hơn bị chôn vùi trong tài liệu cơ sở hạ tầng thị trường của Dusk: trước khi bất kỳ tài sản nào có thể di chuyển, một ví phải được ràng buộc với một bên tham gia đã được Xác minh. Không phải kiểu KYC xong rồi để đó. Ràng buộc theo từng tài sản như một điều kiện chuyển nhượng có thể thực thi.
Tôi muốn kiểm tra xem điều đó thực sự có ý nghĩa gì về mặt cơ học, vì token hóa tuân thủ thường được nói đến một cách khá hời hợt.
Đây là chuỗi mà Dusk mô tả cho việc onboarding kiểu như NPEX: một tổ chức phát hành định nghĩa các quy tắc đủ điều kiện cho tài sản. Ví của nhà đầu tư được ràng buộc với các thông tin/tín chỉ đã được xác minh. Từ thời điểm đó, lớp hợp đồng Transfer sẽ thực thi ai được phép thậm chí nắm giữ hay chuyển token — sự ràng buộc nằm ở lớp thanh toán (settlement), chứ không nằm trong một checkbox ở giao diện người dùng. Bản thân settlement lại gắn kết nhánh tài sản và nhánh thanh toán với nhau để tạo tính tất định (deterministic finality), vì vậy bạn không có trạng thái kiểu cổ phiếu được chuyển nhưng tiền thì không.
Vì sao điều này quan trọng: NPEX là một MTF của Hà Lan dưới sự giám sát của AFM. Nó không thể chỉ trỏ vào một ERC-20 công khai và gọi đó là một chứng khoán. Việc kiểm tra đủ điều kiện phải được thực thi trên chuỗi, chứ không chỉ nằm ở giao diện — nếu không thì phần “được quản lý” chỉ là màn kịch.
Phần tôi muốn xác minh nhưng chưa thấy được mô tả đầy đủ: khi điều kiện đủ điều kiện thay đổi, nhà đầu tư có bị hủy đăng ký không, hoặc khi một quy tắc theo khu vực (jurisdiction) thay đổi đối với các token đã đang nắm giữ thì sao? Việc ràng buộc có bị thu hồi ngược (retroactively) hay chỉ “chặn” các lệnh chuyển trong tương lai?
Đó chính là bài kiểm tra thực sự để xem đây có phải là một hệ thống tài sản được quản lý (regulated asset system) thật hay chỉ là một bài kiểm tra tuân thủ tại thời điểm phát hành.
NPEX di chuyển 300 triệu euro là một điểm dữ liệu. Việc logic kiểm soát chuyển nhượng có đứng vững trước một tình huống biên (edge case) về quản lý đang vận hành hay không mới là thứ quyết định liệu điều này có được áp dụng tổng quát cho phần còn lại của ngành hay không.
Thật sự tò mò là Dusk xử lý trường hợp thu hồi như thế nào — có ai đã đào sâu vào spec Transfer do Zedger/Hedger kiểm soát đủ kỹ để biết không?
@Dusk_Foundation $DUSK #dusk
Điều thu hút sự chú ý của tôi không phải là con số 300 triệu euro gắn với NPEX — mà là một chi tiết nhỏ hơn bị chôn vùi trong tài liệu cơ sở hạ tầng thị trường của Dusk: trước khi bất kỳ tài sản nào có thể di chuyển, một ví phải được ràng buộc với một bên tham gia đã được Xác minh. Không phải kiểu KYC xong rồi để đó. Ràng buộc theo từng tài sản như một điều kiện chuyển nhượng có thể thực thi.
Tôi muốn kiểm tra xem điều đó thực sự có ý nghĩa gì về mặt cơ học, vì token hóa tuân thủ thường được nói đến một cách khá hời hợt.
Đây là chuỗi mà Dusk mô tả cho việc onboarding kiểu như NPEX: một tổ chức phát hành định nghĩa các quy tắc đủ điều kiện cho tài sản. Ví của nhà đầu tư được ràng buộc với các thông tin/tín chỉ đã được xác minh. Từ thời điểm đó, lớp hợp đồng Transfer sẽ thực thi ai được phép thậm chí nắm giữ hay chuyển token — sự ràng buộc nằm ở lớp thanh toán (settlement), chứ không nằm trong một checkbox ở giao diện người dùng. Bản thân settlement lại gắn kết nhánh tài sản và nhánh thanh toán với nhau để tạo tính tất định (deterministic finality), vì vậy bạn không có trạng thái kiểu cổ phiếu được chuyển nhưng tiền thì không.
Vì sao điều này quan trọng: NPEX là một MTF của Hà Lan dưới sự giám sát của AFM. Nó không thể chỉ trỏ vào một ERC-20 công khai và gọi đó là một chứng khoán. Việc kiểm tra đủ điều kiện phải được thực thi trên chuỗi, chứ không chỉ nằm ở giao diện — nếu không thì phần “được quản lý” chỉ là màn kịch.
Phần tôi muốn xác minh nhưng chưa thấy được mô tả đầy đủ: khi điều kiện đủ điều kiện thay đổi, nhà đầu tư có bị hủy đăng ký không, hoặc khi một quy tắc theo khu vực (jurisdiction) thay đổi đối với các token đã đang nắm giữ thì sao? Việc ràng buộc có bị thu hồi ngược (retroactively) hay chỉ “chặn” các lệnh chuyển trong tương lai?
Đó chính là bài kiểm tra thực sự để xem đây có phải là một hệ thống tài sản được quản lý (regulated asset system) thật hay chỉ là một bài kiểm tra tuân thủ tại thời điểm phát hành.
NPEX di chuyển 300 triệu euro là một điểm dữ liệu. Việc logic kiểm soát chuyển nhượng có đứng vững trước một tình huống biên (edge case) về quản lý đang vận hành hay không mới là thứ quyết định liệu điều này có được áp dụng tổng quát cho phần còn lại của ngành hay không.
Thật sự tò mò là Dusk xử lý trường hợp thu hồi như thế nào — có ai đã đào sâu vào spec Transfer do Zedger/Hedger kiểm soát đủ kỹ để biết không?
@Dusk_Foundation $DUSK #dusk