
Trang xem trước của DuskTrade có một số trường dễ bị coi là điểm trang trí UI, nhưng thứ thực sự có thể kéo dự án ra khỏi "khu vực kể chuyện" lại là cái không sexy nhất: Portfolio NAV. Nó xuất hiện cùng với danh sách tài sản, KYC Đã xác minh, Mạng DuskEVM, tương đương với việc thông báo cho bên ngoài một điều: Giai đoạn đầu tiên của DuskTrade không phải là tiếp nhận các tài sản chỉ cần "giao dịch một cách ngẫu nhiên" mà là những thứ có nhịp độ định giá, có ngữ nghĩa thanh toán, có yêu cầu công khai và đối chiếu.
Nhiều sản phẩm giao dịch tiền điện tử không cần phải ghi NAV ra, vì chúng giao dịch các tài sản có việc phát hiện giá liên tục trong 24 giờ, giá chính là thị trường bản thân. Nhưng các tài sản xuất hiện trong bản xem trước của DuskTrade rõ ràng nhắm đến các quỹ được mã hóa, MMF, quỹ thanh khoản chính phủ. Giá trị của chúng không phải là "giá giao dịch biến động bất cứ lúc nào", mà là "định giá có điểm cắt, có tần suất, có độ chính xác". Chỉ cần bạn thừa nhận rằng bạn muốn làm loại tài sản này, bạn phải thừa nhận rằng: cơ chế định giá không phải là việc nhỏ ở hậu trường, mà là ràng buộc cốt lõi của hệ thống giao dịch. Trường Portfolio NAV này được đưa ra, về bản chất là DuskTrade đang công khai hóa ràng buộc này trước.
Một số tên quỹ xuất hiện trong danh mục xem trước được viết rất đầy đủ, chẳng hạn như Quỹ Thanh khoản Chính phủ Euro BlackRock ICS, Quỹ Thanh khoản Chính phủ Bảng Anh BlackRock ICS, Quỹ Tài chính Kho bạc Mỹ BlackRock ICS, Quỹ MembersCap I, và cũng được kèm theo hiển thị giá gần đúng NAV: €103.86, £117.68, $122.26, €100. Ở đây không bàn luận về việc các giá này có phải là thời gian thực hay không, cũng không đoán nguồn dữ liệu, càng không thay nó viết giải thích, chỉ nắm giữ một thực tế quan trọng: nó đang hiển thị giá theo cách “gần giá trị ròng”, chứ không phải bằng cách “hiển thị giá giao dịch”. Kết hợp với trường NAV danh mục, DuskTrade tương đương với việc đặt “tiêu chuẩn định giá” ở lớp đầu tiên của biểu đạt sản phẩm.
Điều này sẽ trực tiếp quyết định hình dạng sản phẩm của DuskTrade. Bởi vì logic giao dịch của các tài sản quỹ, loại MMF về bản chất không phải là giao dịch mọi lúc mọi nơi, mà là hoạt động xung quanh việc cập nhật định giá và cửa sổ mua bán. Nhịp độ định giá của nhiều phần quỹ có thể là hàng ngày thậm chí thô hơn, quỹ thị trường tiền tệ mặc dù có độ biến động thấp, nhưng giá trị của nó vẫn phụ thuộc vào việc tính toán NAV theo tần suất quy định. Nói cách khác, DuskTrade chỉ cần coi NAV như là trường đầu tiên, nó không thể giả vờ mình là một sàn giao dịch thuần túy 24/7 liên tục. Nó phải trả lời một câu hỏi khó hơn: khi việc cập nhật định giá là rời rạc, hành động giao dịch sẽ được định nghĩa trong hệ thống là “hợp lệ” như thế nào.
Đây không phải là lý thuyết ngành, đây là câu hỏi cần trả lời mà DuskTrade bị ép phải giải quyết bởi chính sự lựa chọn của mình. Nếu nó muốn tiếp nhận các quỹ tokenized, nó phải giải quyết ít nhất bốn vấn đề hệ thống rất cụ thể.
Câu hỏi đầu tiên là “thời điểm định giá”. NAV danh mục không phải là một con số đúng mãi mãi, nó chắc chắn tương ứng với một thời điểm nhất định. Nếu thời điểm đó không được hệ thống thể hiện rõ ràng, tất cả giao dịch sẽ trở thành nguồn tranh chấp tiềm ẩn: rốt cuộc nên dùng NAV của kỳ trước hay NAV của kỳ sau, khi nào được coi là “đã cập nhật”, khi nào được coi là “vẫn đang chờ cập nhật”. Trong tài chính truyền thống, những điều này sẽ được viết trong các điều khoản và do các tổ chức trung gian đảm bảo; DuskTrade nếu đặt mình vào môi trường thực thi trên chuỗi, phải biến những thời điểm này thành trạng thái có thể thực thi, nếu không trên chuỗi chỉ trở thành lớp hiển thị, tranh chấp vẫn quay trở lại việc giải thích bằng tay.
Câu hỏi thứ hai là “cửa sổ giao dịch”. Khi việc biểu đạt giá trị tài sản phụ thuộc vào cập nhật rời rạc, giao dịch càng giống như đang thực hiện trong cửa sổ hoặc đang xếp hàng giữa các cửa sổ. Hệ thống phải quyết định: người dùng đặt hàng có được giao dịch ngay trong cửa sổ hay không, hay vào hàng đợi chờ xử lý; giá giao dịch có được khóa vào thời điểm đặt hàng hay không, hay lấy NAV lần tiếp theo làm chuẩn; ranh giới hủy bỏ và hoàn lại ở đâu. Thị trường tiền mã hóa thường coi những điều này là vấn đề trải nghiệm, nhưng trong bối cảnh tài sản được quản lý, chúng là vấn đề ranh giới trách nhiệm. DuskTrade nếu không biến logic cửa sổ và hàng đợi thành cơ chế, chỉ dựa vào văn bản giải thích, quy mô lên cao sẽ bị các tranh chấp đơn hàng xuyên thủng.
Câu hỏi thứ ba là “ý nghĩa đối chiếu trong định giá đa tiền tệ”. Việc xuất hiện đồng thời euro, bảng Anh, và đô la Mỹ trong bản xem trước không phải là đẹp, mà là rắc rối. Định giá đa tiền tệ có nghĩa là không chỉ xử lý hiển thị giá, mà còn xử lý sự không nhất quán trong thời điểm cập nhật giá trị, tiêu chuẩn tỷ giá, và cách tổng hợp NAV danh mục tài sản qua các loại tiền tệ khác nhau. Một khi NAV danh mục được trình bày như một trường cấp tổ hợp, bên ngoài sẽ tự nhiên đặt câu hỏi: NAV này được tổng hợp theo tiêu chuẩn nào, tỷ giá đến từ thời điểm nào, thời gian cập nhật giá trị có đồng bộ không, có tồn tại sự không đồng bộ trong việc cập nhật định giá của các tài sản khác nhau trong tổ hợp dẫn đến “sự lệch lạc NAV tổ hợp”. Nếu những câu hỏi này không thể được diễn đạt lại như quy tắc của hệ thống, độ tin cậy của DuskTrade sẽ bị tiêu hao rất nhanh, vì chính nó đã đặt NAV lên bàn.
Câu hỏi thứ tư là “ranh giới giữa thực thi trên chuỗi và định giá ngoài chuỗi”. DuskTrade đã viết trong bản xem trước rằng Network DuskEVM, điều này có nghĩa là nó thể hiện rằng mình không phải là hệ thống ngoài chuỗi thuần túy. Nhưng việc tính toán giá trị của quỹ và MMF thường đến từ hệ thống ngoài chuỗi, ít nhất trong giai đoạn đầu rất khó hoàn toàn nguyên thủy trên chuỗi. Do đó, ranh giới hệ thống phải rõ ràng: giá trị ngoài chuỗi như thế nào vào trạng thái trên chuỗi, tại thời điểm vào đó làm thế nào để lưu dấu, phiên bản giá trị như thế nào để truy xuất, tác động của phiên bản cũ và mới đối với các đơn hàng chưa thanh toán được định nghĩa như thế nào. Chỉ cần những ranh giới này không rõ ràng, thì trường NAV danh mục càng nổi bật, rủi ro càng lớn, vì nó sẽ đưa tranh chấp từ “không thể thấy” thành “có thể thấy nhưng không thể nói rõ”.
Đó là lý do tại sao tôi cho rằng trường NAV danh mục có thể kiểm tra chất lượng của DuskTrade tốt hơn nhiều câu chuyện lớn lao. Bởi vì nó không phải là một tầm nhìn, nó là một ổ khóa: bạn viết nó ra, cũng có nghĩa là bạn thừa nhận bạn phải đối mặt với sự phức tạp thực sự của định giá và thanh toán. Nhiều dự án sẽ cố tình né tránh những trường như vậy, trước tiên làm cho giao dịch trở nên giống như vậy rồi nói sau; DuskTrade lại đặt nó ở lớp xem trước, lựa chọn này có thể khiến nó khó nói về “điểm hấp dẫn” hơn trong ngắn hạn, nhưng dễ dàng tạo ra “sự khác biệt có thể xác minh” hơn trong dài hạn.
Trong khi đó, trường này cũng sẽ ngược lại ràng buộc con đường mà DuskTrade không thể đi. Chẳng hạn, dựa vào việc tích lũy khối lượng giao dịch bằng tài sản đầu cơ tần suất cao, trong hệ thống NAV tự nhiên không tương thích; dựa vào việc khuyến khích thu hút giao dịch, cũng sẽ xung đột với cửa sổ định giá và logic hàng đợi, vì khuyến khích sẽ thu hút hành vi chiến lược, hành vi chiến lược rất giỏi trong việc lợi dụng thời điểm định giá để thực hiện chênh lệch và tạo ra tranh chấp; và một khi tranh chấp xuất hiện, nền tảng phải có khả năng tái hiện phiên bản NAV, thời điểm và trạng thái đơn hàng lúc đó, nếu không thì tất cả khối lượng thu được từ khuyến khích sẽ trở thành chi phí xử lý.
Vì vậy, xung quanh NAV danh mục, điều DuskTrade thực sự cần cung cấp không phải là “một màn trình diễn đẹp hơn”, mà là một tập hợp các tín hiệu cơ chế có thể được diễn đạt lại, được xác minh. Quan sát sau này xem nó có tiến triển không, không cần xem nó đã nói bao nhiêu lần về tuân thủ, cũng không cần xem nó đã tận dụng bao nhiêu từ khóa RWA hot, chỉ cần chú ý bốn điểm rất cụ thể là đủ.
Thứ nhất, NAV danh mục có hiển thị thời gian cập nhật hoặc nhãn phiên bản hay không, ít nhất cho mọi người biết nó tương ứng với thời điểm định giá nào. Nếu không có thời điểm, NAV chỉ là một chuỗi số; có thời điểm, NAV mới có thể trở thành một phần của trạng thái có thể thực thi.
Thứ hai, liệu các hành động giao dịch xung quanh các quỹ và MMF có xuất hiện biểu đạt sản phẩm “cửa sổ và hàng đợi”, chẳng hạn như giữa việc đặt hàng và giao dịch có tồn tại trạng thái chờ rõ ràng không, đơn hàng có được tính theo NAV hay không, ranh giới hủy bỏ có rõ ràng không. Nếu không có máy trạng thái, tất cả các tranh chấp sẽ quay trở lại việc giải thích bằng tay.
Thứ ba, định giá đa tiền tệ có tương ứng với tiêu chuẩn tổng hợp rõ ràng không, ít nhất là ở mức tổ hợp giải thích cách tổng hợp NAV danh mục. Chỉ cần nó tiếp tục hiển thị tổ hợp tài sản đa tiền tệ, bên ngoài chắc chắn sẽ đặt câu hỏi về tiêu chuẩn đối chiếu, không thể tránh khỏi.
Thứ tư, vai trò mà DuskEVM đảm nhận ở đây có bắt đầu trở nên có thể mô tả: nó chỉ là lớp hiển thị và tương tác, hay đã đảm nhận một phần trạng thái đơn hàng và ràng buộc quy tắc. Chỉ cần vai trò của lớp thực thi không rõ ràng, DuskTrade sẽ bị nghi ngờ là hệ thống ngoài chuỗi gán nhãn lên chuỗi; ngược lại, một khi vai trò của lớp thực thi có thể được diễn đạt lại như một số trạng thái quan trọng được xác nhận và khóa trên chuỗi, độ tin cậy của DuskTrade sẽ lập tức trở nên vững chắc.
Kết luận của bài viết này rất đơn giản: NAV danh mục không phải là một trường dữ liệu đẹp, nó là một ràng buộc cứng mà DuskTrade tự đặt ra cho chính mình. Nó đã kéo dự án từ “thực hiện RWA” đến “xử lý định giá và thanh toán”, cũng đã viết rõ tiêu chuẩn xác minh sau này. Chỉ cần DuskTrade có thể làm cho các thời điểm, phiên bản, trạng thái đơn hàng và tiêu chuẩn đối chiếu của NAV trở thành cơ chế có thể diễn đạt lại trong tương lai, nó sẽ tiến hóa từ “trang xem trước rất giống như vậy” thành “hệ thống đang vận hành theo cách của tài sản được quản lý”. Nếu những cơ chế này vẫn chưa xuất hiện, thì NAV danh mục càng nổi bật, càng trở thành tiêu hao niềm tin, vì nó đã phóng đại vấn đề đến vị trí mà mọi người dùng đều có thể nhìn thấy.
\u003cm-37/\u003e \u003cc-39/\u003e

\u003ct-47/\u003e
