XRPL mở rộng Token Escrow (XLS-85) cho toàn bộ hệ sinh thái token, tăng sức hút DeFi tổ chức

*Theo XRPL.org công bố ngày 12 (giờ địa phương), mạng XRP Ledger(XRPL) đã chính thức mở rộng chức năng *“token escrow”* ra toàn bộ hệ sinh thái, thay vì chỉ áp dụng cho *“Ripple(XRP)”* như trước đây. Bản nâng cấp *“Token Escrow (XLS-85)”* cho phép mọi token trên XRPL – từ token dựa trên trustline (IOU) đến token đa mục đích (Multi-Purpose Token, MPT) – đều có thể sử dụng cơ chế khóa theo thời gian và theo điều kiện ngay trên chuỗi, mở rộng đáng kể hạ tầng thanh toán – thanh toán bù trừ của mạng lưới.*

Theo XRPL.org, đề xuất *“Token Escrow (XLS-85)”* đã được kích hoạt trên *mainnet* ngày 12 tháng 2 (giờ địa phương), sau khi nhận được sự đồng thuận của 30/34 validator, tương đương 88%. Tính năng này được triển khai thông qua phần mềm nút *rippled* phiên bản 2.5.0, trong đó tích hợp đầy đủ thông số kỹ thuật XLS-85. Nhờ vậy, XRP Ledger vốn chỉ hỗ trợ *escrow* cho *“Ripple(XRP)”* nay có thể áp dụng cùng một cơ chế cho cả token trustline (IOU) lẫn *MPT*, đưa toàn bộ lớp tài sản trên mạng vào chung một khung thanh toán – khóa tài sản on-chain linh hoạt hơn.

RippleX – bộ phận phát triển của Ripple – mô tả động thái này là bước chuyển từ mô hình “toàn bộ cấu trúc thanh toán xoay quanh một tài sản gốc duy nhất” sang “mở rộng ra toàn bộ *token stack* trên XRPL”. Trên nền tảng X (trước đây là Twitter), RippleX cho biết: *“Token Escrow (XLS-85) đã chính thức hoạt động trên XRPL mainnet. Tính năng này mở rộng cơ chế escrow gốc từ *Ripple(XRP)* sang toàn bộ token dựa trên trustline (IOU) và MPT. Từ stablecoin như RLUSD đến token hóa tài sản thực (RWA), XRPL giờ đây hỗ trợ thanh toán on-chain an toàn và có điều kiện cho mọi loại tài sản”*. RippleX nhấn mạnh thêm rằng “*bộ công cụ dành cho DeFi tổ chức đã được mở rộng đáng kể*”.

Trang chính thức XRPL.org định nghĩa *“escrow”* trong tài chính truyền thống là dạng hợp đồng mà một bên trung gian thứ ba đứng ra nắm giữ và giải ngân tài sản cho hai bên giao dịch. Trong trường hợp của XRP Ledger, vai trò bên thứ ba này được thay thế hoàn toàn bằng cơ chế tự động tích hợp trong sổ cái. Lâu nay, cơ chế escrow tự động này chỉ áp dụng cho *“Ripple(XRP)”*; với bản nâng cấp *“Token Escrow”*, cùng cấu trúc hợp đồng đó được mở rộng sang mọi loại token *có thể thay thế (fungible)* trên mạng, ngoại trừ NFT.

Về mặt kỹ thuật, token dựa trên trustline và MPT sẽ dùng các *flag* riêng để bật/tắt tính năng escrow. Với token trustline (IOU), tài khoản phát hành phải bật cờ *“Allow Trust Line Locking”* thì token đó mới được phép tham gia vào hợp đồng escrow. Nếu *flag* này tắt, token IOU chỉ có thể chuyển nhượng bình thường, không thể bị khóa trong escrow. Với MPT, các cờ được xác định ngay tại thời điểm phát hành: nhà phát hành phải chỉ rõ *“Can Escrow”* và *“Can Transfer”* để cho phép token vừa có thể bị khóa trong escrow, vừa có thể chuyển đi khi điều kiện hoặc thời hạn được đáp ứng. Hai cờ này cho phép phân tách rõ “token có được phép khóa không” và “sau khi mở khóa có được phép dịch chuyển không”.

Tuy nhiên, XRPL áp dụng một hạn chế quan trọng với tài khoản phát hành: nhà phát hành không được phép tự đưa chính token mình phát hành vào escrow do mình tạo. Nói cách khác, bên phát hành không thể tự khóa token của mình trong các cấu trúc thế chấp hoặc kiểm soát dòng lưu thông mà họ điều khiển trực tiếp. Dù vậy, họ vẫn có thể trở thành *người nhận* token phát ra từ escrow do bên khác tạo. Cách thiết kế này được hiểu là nhằm giảm xung đột lợi ích giữa bên phát hành và cấu trúc phân phối token, hạn chế khả năng thao túng hoặc “khóa – mở khóa” theo ý chí đơn phương.

Cấu trúc *ủy quyền (authorization)* cũng là yếu tố then chốt trong *“token escrow”*. Nếu nhà phát hành thiết lập token ở chế độ “dựa trên phê duyệt” (authorization-based), mọi hành vi tạo – hủy – hoàn tất escrow đều phải thỏa quy tắc kiểm soát truy cập ngay từ đầu. Tài khoản gửi token vào escrow phải được nhà phát hành cấp quyền trước khi hợp đồng escrow được tạo; đến khi escrow hết hạn và bị hủy, tài khoản nhận lại token cũng phải có sẵn quyền nhận do nhà phát hành cấp, bất kể ai là người gửi yêu cầu hủy. Quy tắc này áp dụng xuyên suốt mà không phụ thuộc vào việc bên nào kích hoạt *EscrowCancel*.

Tương tự, tài khoản *người nhận* trong hợp đồng escrow cũng không nằm ngoài cơ chế phê duyệt. Nếu token được cấu hình yêu cầu *authorization*, tài khoản nhận phải được nhà phát hành chấp thuận trước khi giao dịch *“EscrowFinish”* hoàn tất. Trong trường hợp tài khoản nhận chưa được cấp quyền, giao dịch kết thúc escrow sẽ không được chấp nhận. Cách tiếp cận này giúp *“token escrow”* phù hợp với các yêu cầu tuân thủ như chống rửa tiền (AML) hay phát hành token chứng khoán, khi mà cần ràng buộc chặt chẽ quyền truy cập tài sản ngay ở tầng giao thức.

Cũng như trước đây, XRP Ledger tiếp tục hỗ trợ đủ ba dạng escrow: theo thời gian, theo điều kiện và kết hợp. Người dùng khởi tạo khóa tài sản bằng giao dịch *“EscrowCreate”*, mở khóa khi điều kiện được thỏa bằng *“EscrowFinish”*, hoặc thu hồi khi quá hạn bằng *“EscrowCancel”*. Điểm mới với *“token escrow”* là việc thiết lập *“thời điểm hết hạn (expiration time)”* là bắt buộc, không cho phép khóa vô thời hạn. Nhờ vậy, các cấu trúc như vesting, lock-up hay các thỏa thuận phân phối có thời hạn được xem là phù hợp nhất với cơ chế mới.

Về chi phí, XRPL.org lưu ý việc sử dụng *“token escrow”* phát sinh phí cao hơn so với chuyển token thông thường, do tối thiểu cần hai giao dịch (tạo và hoàn tất hoặc hủy escrow). Chi phí tăng rõ hơn khi sử dụng *“Crypto-Conditions”* – cơ chế gắn điều kiện mật mã vào giao dịch. Hiện tại, XRP Ledger hỗ trợ dạng *PREIMAGE-SHA-256* cho *Crypto-Conditions*, khi đó mạng phải xử lý thêm bước xác minh điều kiện, khiến chi phí cho giao dịch *“EscrowFinish”* tăng. Theo tài liệu kỹ thuật, giao dịch *EscrowFinish* kèm *Crypto-Conditions* cần tối thiểu 330 *drop* *“Ripple(XRP)”*, kèm thêm một phần phí tỷ lệ thuận với kích thước dữ liệu *fulfillment*. Cấu trúc phí này sẽ được điều chỉnh tương ứng nếu mức phí cơ bản (base fee) toàn mạng thay đổi.

Tổng hòa lại, *“token escrow”* mang đến sự kết hợp giữa “bảo mật cao và linh hoạt về điều kiện”, đổi lại là mức phí on-chain cao hơn so với chuyển khoản trực tiếp. Với tổ chức và dự án, bài toán đặt ra là cân đối lợi ích của tự động hóa on-chain với chi phí phát sinh, qua đó lựa chọn chính xác những mắt xích thanh toán – thanh toán bù trừ nào nên dùng escrow để tối ưu rủi ro đối tác và rủi ro vận hành.

RippleX liệt kê một loạt kịch bản sử dụng tiêu biểu cho *“Token Escrow (XLS-85)”*: vesting token cho đội ngũ và nhà đầu tư, giải ngân *grant* theo giai đoạn hoặc theo điều kiện, thanh toán có điều kiện và giao dịch OTC, quản lý kho bạc (treasury) như phong tỏa tài sản trong trường hợp tranh chấp pháp lý hoặc làm tài sản thế chấp, và các cấu trúc mở khóa dựa trên token hóa quyền lợi và tài sản thực (RWA). Chẳng hạn, dự án có thể khóa toàn bộ phần token dành cho đội ngũ và nhà đầu tư vào escrow, sau đó thiết lập lịch mở khóa định kỳ on-chain; trong giao dịch OTC, cả tiền và token đều được khóa cho đến khi điều kiện trao đổi song phương được thỏa mãn, từ đó giảm thiểu rủi ro “bên kia không giao”.

Với tài sản thực (RWA), các sự kiện diễn ra ngoài chuỗi như hoàn tất hồ sơ pháp lý, phê duyệt từ cơ quan quản lý hoặc đến hạn đáo hạn có thể được liên kết với *Crypto-Conditions*, để tài sản chỉ được mở khóa khi một điều kiện mật mã đại diện cho sự kiện off-chain đó được thỏa mãn. Điểm chung của các ứng dụng này là nhu cầu về một cơ chế gốc trên nền tảng cho phép “khóa tài sản đến một thời điểm hoặc điều kiện cụ thể” mà không cần phụ thuộc quá nhiều vào bên lưu ký thứ ba hay cơ chế điều phối hoàn toàn ngoài chuỗi.

*Bình luận*: Việc mở rộng *“token escrow”* ra toàn bộ token trên XRPL không chỉ là nâng cấp tính năng mà còn phù hợp với định hướng lâu dài của hệ sinh thái Ripple – xây dựng hạ tầng *DeFi* cho tổ chức với trọng tâm là bảo mật và tuân thủ. Nhờ mở rộng phạm vi escrow từ *“Ripple(XRP)”* sang mọi tài sản trên mạng, XRPL có cơ hội trở thành nền tảng cho các sản phẩm phức hợp dựa trên stablecoin, RWA và token tiện ích – từ giải pháp thanh toán điều kiện đến sản phẩm cấu trúc và thế chấp on-chain. Trong bối cảnh các tổ chức tài chính và nhà đầu tư tổ chức ưu tiên các cơ chế kiểm soát on-chain rõ ràng, *“Token Escrow (XLS-85)”* có thể trở thành mảnh ghép quan trọng giúp XRPL cạnh tranh trong đường đua *“DeFi cho tổ chức”* trong thời gian tới.