#termmax @TermMax Sau khi lãi suất được “đóng gói” thành sổ lệnh, độ sâu của TermMax vẫn thiếu một nhịp nữa
Mở trang báo giá của TermMax, phản ứng đầu tiên của tôi là họ đã biến lãi suất cố định thành sổ lệnh. Không có trò tách PT và YT của Pendle, cũng không có hao mòn quy đổi khi vào/ra pool của Aave. TermMax giống một sàn đấu giá vay mượn trên chuỗi hơn: người đi vay và người cho vay cùng treo lệnh, ngày đáo hạn, lãi suất và tỉ lệ thế chấp đều được phân bổ lên blockchain. $TERM trong hệ thống chỉ là để chiết khấu phí và quyền quản trị, không phải nguồn tạo lợi nhuận—điều này lại khiến tôi thấy yên tâm.
Tôi đã treo lệnh hai lần thực tế: một lần cho mượn USDC, một lần thế chấp ETH để vay stablecoin. Khớp lệnh không nhanh; độ sâu tập trung chủ yếu ở các kỳ hạn 1 tuần và 30 ngày, còn các lệnh từ 90 ngày trở lên gần như phải tự “phá tường”. Trượt giá không phải vấn đề chính; vấn đề là lãi suất được khớp trong cơ chế đấu giá có độ trễ nửa nhịp so với lãi suất thị trường. Khi biến động mạnh, báo giá lãi suất cố định sẽ lệch tạm thời khỏi đường cong phí vốn, rồi vốn chênh lệch sẽ lao vào để “xóa” khoảng lệch đó. Lệnh thủ công thông thường thường không kịp ăn được nhịp này. Việc ghép báo giá của TermMax khá “sạch”, nhưng khi độ sâu mỏng, “sạch” đồng nghĩa với “nguội”.
Về cơ chế thanh lý, đường cảnh báo tỉ lệ thế chấp của TermMax khá thận trọng. So với thanh lý tuyến tính của Aave và cơ chế quyết toán theo đáo hạn của Pendle, nó giống kiểu repo truyền thống hơn—bám giá bên ngoài, theo dõi sát ngoại vi giá. Điểm bất lợi là đòn bẩy không làm cao được; bù lại là tôi ít nhất biết mức kích hoạt nằm ở đâu. Module thế chấp $TERM hiện vẫn chưa được mở hoàn toàn, cách tính miễn/giảm phí cũng còn rối; token quản trị ở giai đoạn này giống như biểu tượng hơn là dòng tiền. Tôi không trông chờ chuyện phần này thay đổi trong ngắn hạn; sự ổn định của thanh lý on-chain còn đáng giá hơn con số lợi suất.
Điều khiến tôi quan tâm nhất là: tiền đi vay theo lãi suất cố định cuối cùng chảy về đâu. TermMax chỉ làm với tài sản “native” gốc—trần lợi nhuận rất rõ ràng. Nếu muốn giành lợi nhuận theo từng lớp với Pendle, hoặc giành vốn tổ chức với Notional, thì họ phải tạo chiến lược lối thoát trước khi đến hạn, chứ không thể chỉ “xếp” APR. Tôi không phủ nhận cơ chế đấu giá này gọn gàng; nhưng giữa “gọn” và “nhộn nhịp”, thứ khác biệt là vận hành thanh khoản. Nhìn lạnh lùng thì hiện tại TermMax giống một mảnh cơ sở hạ tầng lãi suất vẫn còn sắc góc, chưa được mài nhẵn—dùng được, chứ chưa hẳn là dùng tốt. Khi $TERM thực sự gắn với doanh thu của giao thức, có lẽ lúc đó mới là thời điểm nó đáng được định giá lại.
#dusk $DUSK @Dusk nút thắt “chết” của chuỗi công khai quyền riêng tư, Dusk lần này muốn tháo nút ngay từ tầng giao thức
Chuỗi công khai quyền riêng tư trong thời gian dài bị mắc kẹt trong một nút thắt “chết”: làm ẩn danh đến mức cực hạn thì sẽ đụng phải sự giám sát; hậu quả của Tornado Cash đã cho thấy điều đó ở trước mắt. Thế nên, bỏ quyền riêng tư thì cũng đồng nghĩa tự phế võ công. Dusk chọn con đường thứ ba: không né tránh giám sát, mà đưa sự tuân thủ thẳng vào chính bản thân giao thức.
Điểm rơi của nó rất cụ thể. Bộ DuskEVM là lớp tương thích EVM hướng tới tổ chức và nhà phát triển; người quen Solidity gần như không có rào cản để bắt tay vào. Tôi quan tâm hơn đến module quyền riêng tư Hedger: mật mã đồng cấu cộng với chứng minh không kiến thức, để việc tính toán được thực hiện trong bản mã, đồng thời vẫn để ngỏ “cửa” cho việc thẩm tra ủy quyền.
Chỗ thực sự đáng giá của thiết kế này nằm ở khả năng kiểm chứng. Dusk không coi ẩn danh là đích đến; trong bản mã vẫn tính được, sau khi có ủy quyền thì vẫn truy được. Quyền riêng tư và tuân thủ được gộp thành một đường, không phải ép bạn phải chọn một trong hai. Thứ các tổ chức cần không phải là biến mất tuyệt đối, mà là cái gì cần công khai thì công khai, cái gì cần bảo mật thì bảo mật, và luôn có thể lưu vết. Đa số đối thủ hoặc chỉ làm được một nửa: Aztec mạnh ở tính toán phổ dụng, Secret Network dựa vào TEE để tăng hiệu năng, Sapphire của Oasis cũng đi theo hướng EVM nhưng việc tuân thủ lại dừng ở ngoài chuỗi, tự giác. Dusk đưa nó vào tận tầng giao thức—cách nghĩ này đúng nhất với hướng tôi muốn kiểm chứng.
Nhược điểm cũng đã bày sẵn: tài liệu rời rạc, toolchain còn thô; độ trễ của giao dịch quyền riêng tư và Gas phải chờ dữ liệu từ mainnet để nói cho rõ. Nhưng nếu nói nó bị “kẹt chỗ” trong mảng RWA dưới sự quản lý—một ngách cạnh tranh—thì tôi sẵn sàng tin một nửa trước.
dusk gánh vác toàn bộ vận hành của mạng lưới này, câu chuyện từ phía tổ chức có thực sự兑现 được hay không còn tùy nhịp độ triển khai của mainnet DuskEVM, và hệ sinh thái rốt cuộc có ai thật sự đến để dùng hay không. Đường đi theo hướng “@Dusk ” chậm, nhưng chậm có lý do. #dusk
#termmax @TermMax Tường thuật lịch sử của các giao thức cho vay DeFi luôn bị trói buộc bởi lượng tài sản bị khóa (TVL) và tỷ suất lợi nhuận hằng năm (APY). Nhưng thứ thực sự quyết định trải nghiệm lưu giữ người dùng lại là hiệu suất của “động cơ thanh lý” khi thị trường rơi vào trạng thái cực đoan. Gần đây tôi đã bóc tách các tham số thanh lý của TermMax và phát hiện ở cấp độ thiết kế, nó thực sự né được một “căn bệnh” phổ biến trong ngành. Hầu hết các giao thức cho vay đều dùng ngưỡng thanh lý cố định: khi giá biến động xuyên qua ngưỡng đó, người thực hiện thanh lý sẽ lập tức “rút đi” tài sản thế chấp với mức chiết khấu, để lại cho người vay gần như không có thời gian đệm. TermMax chia quy trình thanh lý thành dạng bậc thang: mỗi mức kích hoạt sẽ tương ứng với một tỷ lệ chiết khấu và một cửa sổ thời gian khác nhau. Logic này giống khái niệm “đóng vị thế theo cấp độ” trong tài chính truyền thống hơn là kiểu mua bán một phát trong native của crypto.
Xét theo dữ liệu, đường cong lãi suất vay của TermMax khá mượt hơn Aave v3, và khi hệ số sử dụng vốn nằm trong khoảng 75% đến 90%, mức tăng lãi suất cũng ôn hòa hơn. Thiết kế này có thể đánh đổi một phần lợi nhuận ở phía cung cấp, nhưng đổi lại mang đến sự ổn định cho phía người vay. Trong các tình huống tương tự, cảm giác “nhảy vọt” của lãi suất ở Aave rất rõ: khi hệ số sử dụng vốn vượt ngưỡng, chênh lệch lãi suất mở rộng cực nhanh, không thân thiện với các vị thế vay dài hạn. Hiện tại TermMax dùng token TERM để khuyến khích và quản trị; một số cặp giao dịch có thanh khoản hơi mỏng, nên vấn đề thiếu độ sâu sẽ bị phóng đại khi xảy ra thanh lý quy mô lớn — đây là điểm yếu dễ nhận thấy nhất của nó ở thời điểm hiện tại.
Nếu lấy cơ chế thanh lý “trì hoãn” của Compound để so sánh, nó có đặt cho bên thanh lý một giai đoạn đệm, nhưng điều kiện lại tương đối đơn giản, và nhịp đổi mới sau khi lên V3 diễn ra chậm rãi rõ rệt. Nói về TermMax, thay vì nói rằng nó “giải quyết” được một vấn đề nào đó, thì đúng hơn là nó ghép lại một số hướng tư duy bảo vệ thanh lý cũ theo cách chi tiết và tinh tế hơn. Không thể gọi là một bước nhảy vọt mang tính mô hình mới, nhưng khi vận hành thực tế, bạn vẫn cảm nhận được động cơ của nó “vững tay” hơn khi thị trường chích vào những cú biến động tức thời. Trong ngành có rất nhiều đội ngũ làm cho vay, nhưng số người sẵn sàng “đào sâu” vào các chi tiết thanh lý lại ít. Điều đó khiến TermMax trông có phần khác biệt.
Nhân tiện nói một câu: đừng vội tính APY. Trước tiên hãy đọc phần trong tài liệu của nó về cách bao phủ ký quỹ và các cấp độ thanh lý — sẽ thú vị hơn nhiều so với nhìn vào biểu đồ lợi suất. Dù phép đo lợi nhuận có đẹp đến đâu, nếu logic của động cơ không minh bạch thì khi bước vào giai đoạn gấu, mọi thứ lại lộ nguyên hình.
#dusk @Dusk tháo rời các node và hợp đồng của Dusk, điểm yếu về chuỗi tuân thủ quyền riêng tư không nằm ở cơ chế đồng thuận mà ở công cụ triển khai
Tôi đã chạy thử nghiệm node của Dusk trong hai ngày, tiện tay triển khai một smart contract chuyển tiền bảo mật. Quá trình không mượt: trong tài liệu có vài phiên bản địa chỉ RPC không khớp với nhau, phải lục lịch sử Discord mới ghép được cấu hình đúng. Nếu chỉ nhìn vào cơ chế đồng thuận và việc tạo khối, Dusk không có gì đáng chê; thời gian tạo chứng minh PLONK cũng nằm trong phạm vi chấp nhận được. Nhưng mức độ trưởng thành của toolchain lại rõ ràng đang kéo tụt. DUSK hiện chủ yếu dùng cho gas và tài sản đặt cọc node, nên tập trung hơn vào việc kiểm soát kỷ luật mạng; nhu cầu bên ngoài chưa mạnh.
Điều thực sự khiến tôi băn khoăn là ranh giới giữa quyền riêng tư và tuân thủ. Con đường của Dusk—đi theo hướng hợp đồng bảo mật kèm giao diện kiểm toán/audit—dễ gần với lớp tài sản hơn so với Secret Network vốn thiên về ẩn danh mặc định, và cũng gần hơn so với việc Concordium neo định danh ở ngoài chuỗi. Qua thực nghiệm, vai trò kiểm toán có thể xem những trường dữ liệu đúng là ở mức có thể kiểm soát được, nhưng mô hình ủy quyền vẫn còn khá thô, độ mịn quyền hạn chưa đủ. Các đội ngũ muốn phát hành token dạng chứng khoán rất cần mức cấu hình như vậy. $DUSK được đặt làm ngưỡng truy cập cho quản trị và tuân thủ—hợp lý về mặt logic, nhưng vẫn chưa thực sự “chín” để triển khai.
So với Polymesh, Dusk không tự trói mình vào kịch bản chứng khoán đơn lẻ. Hệ thống tài khoản và quy tắc thanh toán của Polymesh rất cứng; hầu như không thể “chơi” tính toán tổng quát. Dusk giữ lại nhiều không gian hợp đồng hơn, đánh đổi là nhà phát triển phải tự xử lý khá nhiều chi tiết tuân thủ. Tôi lại nghĩ đây chính là sự khác biệt—miễn là bổ sung SDK và tài liệu. $DUSK lợi suất từ đặt cọc có thể bù một phần lạm phát; nhưng khi số lượng ứng dụng hệ sinh thái quá ít, lợi suất đó chỉ còn là con số trên giấy.
Nếu sau này họ sắp xếp lại từ đầu việc triển khai node, công cụ kiểm toán và tài liệu cho nhà phát triển, thì Dusk trên tuyến đường RWA về quyền riêng tư là có chỗ đứng. Hiện tại nó vẫn đang ở giai đoạn giao thức đã chạy được còn hệ sinh thái chưa đến; DUSK vì vậy phù hợp để quan sát hơn là vội vàng đặt cược.
#dusk $DUSK @Dusk Chuỗi quyền riêng tư ai cũng đang hô “tuân thủ”, nhưng Dusk là một trong số ít dự án biến câu đó thành hiện thực trong kiến trúc.
Nhìn Dusk trong khoảng thời gian này, cảm nhận lớn nhất của tôi là nó không giống đang làm một thứ “chủ nghĩa nguyên giáo” về quyền riêng tư. Ngược lại, khả năng kiểm toán được đặt lên trước cả tính ẩn danh. Sự kỷ luật này rất hiếm trong lĩnh vực quyền riêng tư, và cũng là một phần trong logic dài hạn $DUSK bị đánh giá thấp. Giải pháp PLONK của nó không giấu toàn bộ giao dịch, mà để lại “khe hở” cho kiểm toán tuân thủ. Trong bối cảnh token hóa chứng khoán, cách tiếp cận này thực tế hơn nhiều so với việc chỉ thuần ẩn giấu.
Đọc lại tài liệu của họ thì thấy phần dành cho nhà phát triển hơi quanh co. Việc đồng bộ node testnet tới một mốc nào đó sẽ bị dừng, cần phải tự dọn dẹp trạng thái rồi chạy lại. Tôi đoán đa số người khi chạy node lần đầu sẽ vướng ở đây, và đường hướng khắc phục trong tài liệu cũng chưa đủ trực tiếp. Những chi tiết kiểu này không hề nhẹ đối với các đội muốn nghiêm túc tích hợp RWA, vì chi phí ma sát rất cao. Secret Network mặc định quyền riêng tư trên toàn chuỗi, trải nghiệm giao dịch mượt mà hơn, nhưng công cụ tuân thủ yếu hơn một bậc; Oasis thiên về quyền riêng tư dữ liệu, độ sâu giao thức ở lớp tài sản tài chính không bằng Dusk; Concordium có danh tính on-chain, còn khả năng quyền riêng tư của smart contract lại ở mức bình thường. Vấn đề của Dusk là hệ sinh thái còn lạnh, bộ công cụ chưa đủ để chống đỡ một cộng đồng nhà phát triển sôi động.
Tôi không quá đồng tình với việc nói đơn giản Dusk là “nền tảng token hóa chứng khoán tiếp theo”. Những gì nó làm là tìm một con đường có thể triển khai giữa quyền riêng tư dạng chứng minh và các nút giám sát. Chỉ là hiện tại, con đường này dường như mới dừng nhiều ở thiết kế giao thức; các công cụ phát hành khả dụng và thanh khoản on-chain vẫn còn thiếu. So với nhiều dự án quyền riêng tư khác, họ coi “tuân thủ” như từ ngữ marketing; còn Dusk thì ngược lại, đã dành sẵn trong tầng giao thức các “cổng” cho danh tính và kiểm toán. Câu chuyện về giá rất dễ bị RWA dẫn dắt, còn nhịp xác thực kỹ thuật lại chậm—khoảng cách giữa hai yếu tố này cần thời gian để tiêu hóa.
Với những ai muốn theo dõi lâu dài, trọng điểm không phải là chăm chăm vào tăng giảm ngắn hạn, mà là xem liệu nó có thể bù lại trải nghiệm của node và các giao diện tuân thủ hay không. “Hố” của quyền riêng tư - tuân thủ, rất nhiều dự án vấp ở chỗ nói nhiều làm ít; Dusk ít nhất đến hiện tại viết thì vẫn đẹp hơn làm, và vẫn cần bàn giao chắc chắn hơn.
#dusk $DUSK @Dusk Đã đưa tính tuân thủ vào lớp quyền riêng tư, nhưng lại không đưa sản phẩm ra khỏi CLI
Những ngày này, tôi đã xem lại mạng thử nghiệm và tài liệu của Dusk một lần nữa. Tôi không thấy lộ trình toàn là lời hứa suông—tôi chỉ thử qua ba lối vào: nút (node), chuyển tiền và trình duyệt khối (block explorer). Những gì Dusk muốn làm trong lĩnh vực quyền riêng tư không phải là mới: biến việc xử lý quyền riêng tư cho tài sản thuộc diện quản lý thành năng lực mặc định trên chuỗi. Nhưng cách họ nhét “định danh tuân thủ” trực tiếp vào cấu trúc giao dịch thì lại không giống Secret hay Oasis. Secret thiên về các hợp đồng quyền riêng tư dùng chung; Oasis dựa vào TEE để tách biệt; còn Dusk giống như trước hết công khai khả năng kiểm toán, rồi dùng bằng chứng không tri thức để nén lượng thông tin. Hướng đi không tệ, nhưng ở tầng sản phẩm thì rõ ràng chậm hơn một nhịp.
Chi phí tài nguyên khi chạy node không phải là quá đáng kể, với các trình xác thực (validator) cỡ vừa và nhỏ thì khá thân thiện. Vấn đề chủ yếu nằm ở luồng tương tác. Một giao dịch chuyển tiền “riêng tư” gửi đi, khi quay lại trình duyệt khối thì hầu như không thấy được trạng thái thay đổi có thể đọc được; bạn chỉ có thể quay về CLI để xem nhật ký sự kiện. Cách “nửa trong suốt” này có thể chấp nhận được với mục tiêu quyền riêng tư, nhưng với các đội ngũ làm kiểm toán tuân thủ thì sẽ khá khó chịu. Tài liệu SDK của Dusk cũng có chỗ bị đứt gãy: ví dụ cơ bản chạy được, nhưng hễ đụng tới việc tách quyền và công bố chọn lọc thì lại không có phần tiếp theo. So với Polymesh, công cụ cho lớp định danh của Polymesh tinh tế hơn nhiều—các quy tắc vai trò và chữ ký có thể cấu hình ngay khi mở ra.
Về mảng token, hiện tại việc bắt giá trị của token mạng Dusk vẫn xoay quanh staking và phí, không thấy nhiều khác biệt trong trọng số quản trị. Họ kể câu chuyện “tuân thủ” cho thị trường thứ cấp thì dễ tạo niềm tin, nhưng nếu muốn để tổ chức thực sự đưa tài sản lên đó, vẫn thiếu một mô-đun luân chuyển định danh mà không phụ thuộc vào KYC thủ công. Oasis và Concordium xử lý ranh giới giữa định danh riêng tư và tuân thủ on-chain trưởng thành hơn; nếu Dusk chỉ dừng ở phần demo trên testnet, khoảng cách chỉ có thể tiếp tục nới rộng.
Tôi không nghi ngờ giá trị dài hạn của con đường public chain về quyền riêng tư—thậm chí tôi còn cho rằng góc tiếp cận mà Dusk chọn còn có khả năng trụ vững trước sự giám sát tốt hơn so với câu chuyện thuần ẩn danh. Nhưng ở giai đoạn hiện tại, tôi lại cảm giác tham vọng ở tầng giao thức lớn hơn mức hoàn thiện ở tầng ứng dụng. Thay vì tiếp tục nhấn mạnh “thân thiện với tuân thủ”, thì chi bằng trước hết kéo nhà phát triển ra khỏi lệnh dòng (command line): bổ sung trình duyệt và các công cụ định danh cho đầy đủ.
#dusk $DUSK @Dusk Khi quảng bá hiệu năng của chain công khai, thông thường người ta chỉ nói về thời gian tạo khối và thông lượng, còn chi phí băng thông thì ít khi được đưa lên bàn. Thế nhưng, khi số lượng nút tăng lên, cùng một thông điệp bị chuyển tiếp lặp đi lặp lại; mạng còn chưa kịp chạm đến nút thắt về năng lực tính toán thì bộ định tuyến và hàng đợi đã bắt đầu ùn tắc. Dusk đặt Kadcast ở tầng nền: mạng tài chính không chỉ cần chạy nhanh, mà còn phải đảm bảo các nút với cấu hình khác nhau liên tục nhận cùng một loạt khối và phiếu bầu
Kadcast không để các nút Dusk tùy tiện ném thông điệp cho một vòng hàng xóm. Nó duy trì các “buckets” định tuyến dựa trên khoảng cách XOR theo định danh nút, rồi phân phối thông điệp theo từng cấp, tạo ra một lộ trình lan truyền có cấu trúc. Các nút ở xa không cần phải trải qua một chuỗi chuyển tiếp dài dòng, nên việc truyền lặp cũng giảm đáng kể. Thiết kế này giống như sắp xếp cho dữ liệu những điểm trung chuyển cố định: tuyến đường dễ dự đoán hơn, nhưng đồng thời bảng định tuyến cần “tươi” hơn, chất lượng từng bucket và cơ chế phát hiện nút cũng trở nên quan trọng hơn
Đưa các nút Dusk vào môi trường vận hành, thứ tự kiểm tra của tôi khá thực tế: cổng nhận có truy cập được không, NAT có cấu hình sai không, nút có tìm thấy được bao nhiêu “người quen” đồng hành, trước khi đồng bộ có thiết lập đủ kết nối hay chưa, và chiều cao khối có liên tục tiến lên hay không. Giao thức kiểu Gossip có vẻ “cồng kềnh”, nhưng lại đánh đổi tính dư thừa để đổi lấy khả năng chịu lỗi; Kadcast thì tiết chế hơn và dựa nhiều hơn vào cấu trúc định tuyến đúng đắn. Nếu một vài nhánh tuyến đường quan trọng bị hỏng hoặc các bucket bị các nút độc hại chiếm giữ, phần băng thông “tiết kiệm được” có thể chuyển thành độ khó gỡ lỗi
Trong whitepaper, Dusk đưa ra dữ liệu tiết kiệm băng thông tương đối so với Gossip khoảng một phần tư đến một nửa, và trong kịch bản mạng tốc độ cao thì giảm tỷ lệ khối rác từ 10% đến 30%. Những con số này đến từ bối cảnh mô phỏng trong bài nghiên cứu, không phải kết quả Mainnet có thể tái hiện bất cứ lúc nào—dùng trực tiếp làm khẩu hiệu quảng bá thì chưa thật thận trọng. Giá trị hơn là việc xác minh trong thực tế: khi các nút thường xuyên bật/tắt, độ trễ xuyên khu vực và tình trạng tắc nghẽn đột phát, cần ghi nhận phân bố thời điểm thông điệp đến, thay vì chỉ nhìn vào giá trị trung bình
Dusk cũng yêu cầu các nút xác thực chữ ký của thông điệp, và trong cùng một bucket định tuyến lưu giữ các đồng bạn dự phòng. Cái trước lọc nội dung giả mạo; cái sau xử lý tình huống một nút đơn lẻ ngoại tuyến. Người đặt cọc DUSK gánh vác nhiệm vụ tạo khối và bỏ phiếu, nên hiệu quả lan truyền cuối cùng sẽ rơi vào cơ chế phần thưởng, hình phạt và ngưỡng tham gia. Băng thông càng dễ kiểm soát thì người vận hành bình thường càng có khả năng ở lại trong tập xác thực; cấu trúc càng phức tạp thì việc giám sát và kiểm toán càng không thể xem nhẹ. TPS là con số trên sân khấu; bảng định tuyến của Kadcast mới là cầu chì ở hậu trường. Nó không sáng, nhưng lại quyết định Dusk có bất ngờ “mất điện” ở giữa màn diễn hay không
#dusk $DUSK Tôi đã xem @Dusk và hiểu lầm đầu tiên cần loại trừ là coi nó như một sàn giao dịch phi tập trung khác. Thứ Dusk muốn làm là trở thành cổng cho một nhà môi giới mới dành cho tài sản tài chính được token hóa. Trên trang có xuất hiện quỹ thị trường tiền tệ, trái phiếu, cổ phiếu và ETF; con đường người dùng cũng không phải cứ kết nối ví là giao dịch bừa. Thay vào đó, họ phải hoàn tất xác minh danh tính trước, rồi mới chọn các tài sản phù hợp điều kiện, đồng bộ việc thanh toán, nắm giữ và thanh toán bù trừ. Định vị này có thể không “điên” nhưng lại gần với thực tế tài chính hơn. Vấn đề là: càng tiến gần tới mô hình nhà môi giới chứng khoán thì sản phẩm càng không thể chỉ hiển thị lợi suất đẹp và danh sách tài sản.
Trải nghiệm mà Dusk thực sự nhắm tới không chỉ là các nền tảng RWA kiểu Ondo, mà còn gồm cả Robinhood và các công ty chứng khoán mạng lưới đã trưởng thành. Các nhà môi giới truyền thống nhét việc mở tài khoản, nạp tiền, báo giá, đặt lệnh và báo cáo vị thế vào một giao diện duy nhất; người dùng hầu như không quan tâm tới hệ thống thanh toán bù trừ nằm phía sau tài sản. Nếu Dusk yêu cầu người dùng hiểu mạng ví, số dư trên chuỗi, trạng thái giao dịch và quyền riêng tư thì lợi thế công nghệ sẽ biến thành chi phí học tập. Tôi mong Dusk đưa “chuỗi” sang chế độ hậu trường (backend), để người dùng thấy rõ khu vực có thể đầu tư, số tiền tối thiểu, phí, thời gian khớp lệnh và quy tắc hoàn trả/chuộc lại, thay vì bắt họ đoán từng bước diễn ra điều gì.
Điểm mạnh của Dusk là: họ không chỉ cố gắng “bọc” token cho một nhóm tài sản hiện có, mà muốn nối liền thành một chuỗi nghiệp vụ từ xác thực tư cách, quyền sở hữu, giao dịch đến giao nhận cuối cùng. Làm như vậy có cơ hội giảm ghi sổ trùng lặp giữa nhiều hệ thống, đồng thời giúp tài sản đi vào nhiều ứng dụng trên chuỗi hơn. Tính “tổ hợp” (composability) nghe thì rất hay, nhưng ngoài đời luôn có ranh giới. Dusk phải giải thích rõ tài sản nào có thể dùng làm tài sản thế chấp, tài sản nào chỉ được nắm giữ; sau khi được gọi qua các ứng dụng khác nhau thì ai chịu trách nhiệm tuân thủ; và nếu hợp đồng thông minh xảy ra lỗi thì tài sản có thể được tạm dừng hay không. Nếu thiếu các “tấm chắn” đó, việc mở hạ tầng nền tảng lại có thể làm rủi ro gia tăng.
Hiện tại Dusk vẫn đang ở giai đoạn trước khi ra mắt (pre-launch), nên giao diện thị trường trên website chỉ có thể nói về hướng sản phẩm, chứ không chứng minh được thanh khoản thực sự. Tôi không cần biết danh sách chờ dài bao nhiêu, mà muốn xem các tài sản đợt đầu có thể được niêm yết liên tục hay không, chênh lệch giá mua-bán có hợp lý không, việc hoàn trả/chuộc lại có thực hiện đúng cam kết không, các tài liệu về hành động của doanh nghiệp và hồ sơ thuế có rõ ràng không, và bộ phận hỗ trợ có thể xử lý các tình huống mà hồ sơ trên chuỗi không khớp với hồ sơ pháp lý hay không. Nếu Dusk có thể xử lý vững các vấn đề “khô khan” này, họ mới có khả năng bước ra khỏi câu chuyện RWA để trở thành một sản phẩm tài chính thực sự có thể sử dụng.
Cảm giác rằng thế giới số trong tương lai chắc chắn sẽ xuất hiện nhiều mô hình đổi mới hơn. #宇宙之心 chọn văn minh liên hành tinh làm điểm khởi đầu, kết hợp trí tưởng tượng và blockchain. Mặc dù con đường sẽ không hề đơn giản, nhưng hướng đi khá đặc sắc. #宇宙之心 $SPCX
Khi việc thế chấp Bitcoin gặp lãi suất cố định, biến số mà các tổ chức sợ nhất vừa mới bị loại bỏ
Tôi cho rằng bước tiếp theo đáng theo dõi của Babylon Trustless Bitcoin Vaults là chuyển chi phí vay BTC gốc từ con số biến động sang một điều khoản có thể dự toán được. Babylon và Aegis đang lên kế hoạch kết nối TBV, Aave v4 và tín dụng lãi suất cố định, mục tiêu là quý IV năm 2026, nhưng vẫn phụ thuộc vào phát triển và thử nghiệm. Chi tiết này không thể bỏ qua—kế hoạch không đồng nghĩa với việc đã ra mắt.
Hướng đi của Babylon đã trúng đúng “điểm đau” của BTCFi hiện tại. Người quản lý vốn không chỉ nhìn vào tỷ lệ thế chấp, mà quan trọng hơn là sau ba hoặc sáu tháng thì rốt cuộc phải trả bao nhiêu tiền lãi. Lãi suất thả nổi kiểu Aave phù hợp với thanh khoản ngắn hạn, nhưng sẽ biến động theo mức sử dụng vốn. Lãi suất cố định khóa sự biến động vào cấu trúc sản phẩm, giúp kho bạc, quỹ và vốn tạo lập thị trường có thể tính lợi nhuận ròng trước rồi mới quyết định có vay hay không. Nghe không “đã mắt”, nhưng lại gần hơn với những thứ mà tổ chức sẵn sàng ký duyệt.
So với khoản vay Bitcoin tập trung, lợi thế của Babylon không nằm ở việc lãi suất chắc chắn thấp hơn, mà ở việc BTC gốc vẫn bị ràng buộc bởi TBV: quy tắc vay và trạng thái thế chấp có thể kiểm chứng, không cần giao cả đồng coin và cam kết thanh toán cho một bên cho vay duy nhất. Tuy vậy, nó cũng khó làm hơn các pool lãi suất thả nổi thông thường trên chuỗi. Nguồn vốn có kỳ hạn đến từ đâu, cách định giá việc trả trước và xử lý sai lệch kỳ hạn—làm sao để khớp được thanh khoản của Aave với báo giá của Aegis—không thể che bằng một con số cố định.
Đánh giá trải nghiệm sản phẩm của Babylon của tôi sẽ bám vào vài chi tiết. Trang phải hiển thị đồng thời lãi suất danh nghĩa, phí giao thức, chi phí thực thi xuyên chuỗi và thời gian thoát ra trong kịch bản xấu nhất. Lãi suất cố định không chỉ phải có lợi cho người vay, mà còn phải giúp bên cung cấp vốn nhìn rõ thời hạn bị khóa và phần bù rủi ro. Nếu đến gần ngày đáo hạn mới lộ ra tình trạng thiếu thanh khoản, thì thứ gọi là “tính chắc chắn” thực ra chỉ chuyển biến động từ mục lãi suất sang giai đoạn thanh toán—nhìn bình tĩnh hơn, điều đó lại càng khó xử lý.
Ý nghĩa của việc Babylon biến TBV thành một lớp thế chấp nền tảng mang tính mô-đun cũng thể hiện ở đây. Aave cung cấp pool vốn, Aegis thiết kế sản phẩm theo kỳ hạn, Babylon giữ vững ranh giới thế chấp của BTC gốc. Quan điểm còn dè dặt của tôi là: càng nhiều lớp hợp tác thì càng dễ đẩy qua đẩy lại về phí, quản trị và trách nhiệm khi có sự cố. Việc Q4 có thể giao ra một chuỗi liên kết hoàn chỉnh, minh bạch và đo được, quan trọng hơn cả danh sách các bên tham gia. Tôi sẽ tiếp tục theo dõi việc giao @BabylonLabs_io , và cũng đưa $BABY vào khung quan sát về phối hợp quản trị lẫn hệ sinh thái.#baby
UTXO 不 thể cắt đôi, đề thi TBV giấu trong khoảnh khắc thanh lý
Mình thấy Babylon Trustless Bitcoin Vaults (TBV) khá thú vị: không phải điểm hay nằm ở việc cho mượn test coin, mà là việc nó “đụng” vào giới hạn cấu trúc của Bitcoin. Các vị thế Aave thông thường có thể xử lý theo tỉ lệ, nhưng kho bạc của Babylon ứng với toàn bộ UTXO, nên thanh lý chỉ có thể lấy cả “một lần nguyên khối”. Một kho bạc nghe thì gọn việc, nhưng dao động nhỏ cũng có thể kích hoạt xử lý toàn bộ vị thế—hiệu ứng vách vực này đáng theo dõi hơn cả lãi suất. Sức khỏe của testnet Babylon không chỉ bị ảnh hưởng bởi giá BTC; lãi suất nợ cũng liên tục đẩy rủi ro lên. Đi ngang không có nghĩa là vị thế an toàn; chỉ nhìn giá thôi, một kho bạc đơn vẫn có thể từ từ trượt tới đường thanh lý.
Babylon chia vị thế thành hai kho bạc: phần xử lý trước nằm ở kho bạc đầu, còn phần BTC lại được giữ ở kho bạc sau. Khi sức khỏe tụt xuống dưới ngưỡng biên, giao thức lần lượt lấy đi đủ giá trị của từng kho bạc theo thứ tự, không quét sạch toàn bộ vị thế. Cách này còn “hơi mệt đầu” hơn WBTC thế chấp: tài sản được bọc/đóng gói có thể tách được, và người dùng không cần tự quản lý thứ tự thanh lý. Babylon giữ lại BTC gốc, nhưng biến việc sắp xếp thành một nút bấm rủi ro. Nếu trang không hiển thị kết quả tổn thất ở các mức giá khác nhau, việc khuyến nghị tách cũng có thể bị cấu hình sai. Babylon cho phép điều chỉnh thứ tự kho bạc; quản trị rủi ro không kết thúc khi hệ thống vừa được tạo. Khi tham số thay đổi, kho bạc ở phía trước có thể không còn đủ để hấp thụ thanh lý; nếu trang không tự động tính lại, người dùng sẽ rất khó biết nên sắp xếp thế nào.
Thanh lý trên Ethereum có thể hoàn tất ngay, còn việc chuộc trên Bitcoin thì phải chờ “cửa sổ chứng minh”. LLP sẽ trả trước cho người thực hiện thanh lý WBTC, rồi các nhà kinh doanh chênh lệch (arbitrage) tiếp nhận kho bạc và thực hiện chuộc BTC. So với các nền tảng tập trung giấu lỗ vào sổ cái, Babylon minh bạch hơn, nhưng vẫn có phụ thuộc. Độ sâu của LLP, sai lệch oracle, độ trễ chứng minh và thanh khoản của WBTC—chỉ cần một trong các yếu tố này bị mỏng đi trong trạng thái cực đoan của thị trường, thì “thanh lý nguyên tử” cũng sẽ bị chiết khấu. Babylon sẽ dùng giá trị xử lý vượt mức để giảm nợ hoặc trả lại bằng WBTC. Quy tắc tính toán có vẻ công bằng, nhưng không đồng nghĩa trải nghiệm không có chênh lệch; khi WBTC bị chiết khấu hoặc thanh khoản căng thẳng, phần “bù danh nghĩa” và “giá trị thực” vẫn có thể xuất hiện khoảng hở.
Mình đánh giá về @BabylonLabs_io rất đơn giản: thắng thua của TBV không nằm ở việc có mượn được trong bull market hay không, mà nằm ở việc trong đợt sụp giá mạnh có thể mượn ít, kết toán nhanh và hoàn trả phần dư một cách công bằng. Nếu testnet có thể hiển thị trực quan mô phỏng hai kho bạc, cảnh báo thanh lý và kế hoạch bù, thì “tín nhiệm” của BTC gốc mới thực sự dùng được. $BABY nên phục vụ tốt cho việc tham số rủi ro, quản trị và nâng cấp an toàn; không cần gánh chuyện kể giá cả. #baby
@Velvet_Capital Ra mắt cuộc thi giao dịch hợp đồng vĩnh viễn mới nhất: tổng giải thưởng là 75 triệu GEMS, chia thành 2 pool cạnh tranh là PNL và Volume, sự kiện sẽ kết thúc vào ngày 9 tháng 8. Đơn vị tổ chức cũng đã liên kết cuộc thi này với việc phân bổ 2,7 triệu mã $VELVET vào Epoch 11 ngày 10 tháng 8.
Khi thấy cụm “có thể đồng thời cạnh tranh ở cả hai pool”, nhiều người sẽ nghĩ ngay: vừa tăng lợi nhuận, vừa cố gắng đẩy khối lượng giao dịch càng lớn càng tốt.
Nhưng khi đặt hai mục tiêu này cùng nhau, chúng lại dễ khiến hành động giao dịch bị méo mó nhất.
Giả sử có hai nhà giao dịch đều có 1.000 USD vốn. A chỉ thực hiện 2 lần giao dịch chắc chắn, cuối cùng lãi 120 USD, tổng khối lượng giao dịch tích lũy là 8.000 USD; trong khi B để lao vào cuộc đua Volume thường xuyên mở và đóng lệnh, khiến tổng khối lượng giao dịch lên tới 100.000 USD, lợi nhuận gộp trên sổ sách 50 USD, nhưng sau khi trừ phí giao dịch, trượt giá và chi phí funding, kết quả thực tế có thể đã chuyển thành lỗ.
A đi theo tư duy PNL nhiều hơn, B đi theo tư duy Volume nhiều hơn. Cả hai cùng tham gia một cuộc thi, nhưng lại gánh những chi phí và rủi ro hoàn toàn khác nhau.
Vì vậy, thứ thực sự cần tính không phải là trên trang cộng thêm bao nhiêu GEMS, mà là: kết quả thực tế = PNL đã thực hiện − phí giao dịch − chi phí funding − tổn thất do trượt giá.
Đặc biệt với hợp đồng vĩnh viễn, tăng đòn bẩy có thể nhanh chóng khuếch đại khối lượng giao dịch danh nghĩa, nhưng đồng thời cũng rút ngắn khoảng cách giữa vị thế và giá thanh lý. Việc mở thêm vài vị thế để leo bảng xếp hạng sẽ không làm thị trường dễ đoán hơn; một giao dịch đòn bẩy cao bị mất kiểm soát có thể xóa sạch toàn bộ PNL đã tích lũy và kỳ vọng tiền thưởng trước đó.
Nếu chủ yếu cạnh tranh ở pool PNL, tôi sẽ quan tâm hơn đến tỷ lệ thắng, tỷ lệ lãi/lỗ và mức drawdown tối đa; không phải vì muốn giảm tiêu chuẩn vào lệnh để tăng số lần giao dịch. Nếu chủ yếu cạnh tranh ở pool Volume, thì cần đặt trước ngân sách phí giao dịch có thể chấp nhận, giới hạn trần đòn bẩy và khối lượng giao dịch trong ngày; khi chạm ranh giới rủi ro thì dừng lại.
Còn một điểm nữa cần phân biệt: 75 triệu GEMS là quy mô phần thưởng của cuộc thi, không có nghĩa là mỗi người tham gia đều nhận được một số lượng cố định; thứ hạng cuối cùng, số lượng người tham gia và quy tắc phân bổ sẽ ảnh hưởng đến kết quả của từng cá nhân.
Giá thị trường của $VELVET cũng sẽ biến động, vì vậy không thể chỉ dùng định giá hiện tại để suy ra lợi nhuận ổn định.
Cuộc thi này thực sự không kiểm tra ai phản hồi nhanh hơn, mà là ai có thể vẫn giữ kỷ luật giao dịch của mình ngay cả khi tăng số hoạt động giao dịch.
Bảng xếp hạng sẽ kết thúc, nhưng thói quen giao dịch sai lầm có thể vẫn còn lại.
Bitcoin không cần rời khỏi chuỗi vẫn có thể đi vay, TBV thật sự có ngưỡng là trải nghiệm
Nếu tách quy trình của testnet công khai ra từng bước, logic của Babylon Trustless Bitcoin Vaults (TBV) rất trực tiếp: BTC gốc được khóa trên mạng Bitcoin dưới dạng Taproot UTXO độc lập, trạng thái thế chấp được xác minh ở phía Ethereum, rồi thông qua Aave v4 để vay tài sản thử nghiệm. So với WBTC, cbBTC do bên giám sát đúc/mint, Babylon chuyển niềm tin sang hợp đồng script, bằng chứng và giao thức mục tiêu—không phải đổi tên rồi “cross-chain”. Lộ trình này không phải là ánh xạ BTC thành một đồng token khác, mà là để ứng dụng bên ngoài đọc được trạng thái thế chấp có thể được kiểm chứng. Câu chuyện nghe có vẻ tương đồng, nhưng quyền kiểm soát tài sản lại hoàn toàn khác.
Điểm sáng của Babylon không chỉ là tự giám sát (self-custody). Các “kho” (vault) được cách ly với nhau, tài sản không đi vào một pool chia sẻ, và giao thức cũng không thể tiếp tục thế chấp lại; sau khi thanh toán xong, bằng chứng sẽ kích hoạt việc chuộc BTC. Cấu trúc như vậy có thể hỗ trợ cho vay, stablecoin và bảo hiểm—giống như một lớp nền thế chấp native của Bitcoin hơn là lại thêm một loại tài sản bọc (wrapped). Đặc biệt với thiết kế “mỗi vault, mỗi UTXO”, khi một vị thế có vấn đề, sẽ không tự nhiên kéo những người gửi tiền khác vào cùng một pool tài sản.
Cũng cần dội một gáo nước lạnh. Babylon vẫn đang ở testnet công khai; người dùng phải xử lý signet BTC, tài sản trên Sepolia, kích hoạt vault và khoản vay; việc chờ/đợi giữa các chuỗi và các thông báo lỗi vẫn còn khá thô. Tài sản thử nghiệm không có giá trị, lại đúng là phù hợp để phơi bày vấn đề tương tác. Nếu việc kích hoạt bị kẹt, giao diện Babylon phải nói rõ kẹt ở chỗ xác nhận trên Bitcoin, kẹt ở khâu tạo bằng chứng, hay kẹt ở khâu thực thi trên Ethereum. Sau khi tạo một vault đơn lẻ còn bị ràng buộc với một ứng dụng cụ thể—ranh giới an toàn rõ ràng, nhưng điều phối vốn lại ít linh hoạt hơn.
Nhận định của tôi về Babylon thiên về thận trọng: TBV vay được tiền chỉ là điểm khởi đầu. Sự minh bạch khi thanh lý có đảm bảo hay không, việc chuộc có ổn định hay không, và ví có thể nén quy trình thành vài lần xác nhận hay không—mới là những yếu tố quyết định liệu nó có bước ra khỏi “vòng kỹ thuật” được không. $BABY lẽ ra phải đảm nhận quản trị và mở rộng giao thức, không nên dựa vào tưởng tượng giá để chống đỡ câu chuyện. @BabylonLabs_io #baby $BABY
Mã giới thiệu có thể giúp tiết kiệm 5%, nhưng thứ thực sự cần tính là tổng chi phí giao dịch
@HertzFlow Bài hướng dẫn dành cho người mới vừa được đăng tải phần 3 mới nhất, tập trung phân tích chi tiết hệ thống Referral (Giới thiệu). Trước khi xem trang chính thức, tôi cứ nghĩ đây chỉ là một chương trình mời thông thường. Xem kỹ xong mới phát hiện người giới thiệu và người được giới thiệu đảm nhận hai vai trò khác nhau.
Sau khi người dùng liên kết một mã giới thiệu hợp lệ gồm sáu chữ số, trong các giao dịch ở chế độ Normal đáp ứng điều kiện, sẽ nhận được mức giảm 5% cho phí mở và phí đóng vị thế. Đồng thời, người tạo mã giới thiệu và mời người khác có thể nhận hoàn tiền theo hai tầng quan hệ: mời trực tiếp theo L1 và mời gián tiếp theo L2.
Cùng một ví có thể trước tiên liên kết mã giới thiệu của người khác, rồi tạo mã của riêng mình để mời những người khác, nhưng không thể tự mời chính mình. Hiện tại, nền tảng cũng cho phép liên kết lại mã. Mối quan hệ mới chỉ ảnh hưởng đến các giao dịch sau này, không truy ngược để thay đổi các chiết khấu và dữ liệu thống kê trong quá khứ.
Điểm dễ hiểu nhầm nhất là phạm vi của “giảm giá 5%”. Mức giảm này chỉ áp dụng cho phí mở/đóng vị thế ở chế độ Normal thỏa điều kiện, không bao gồm Funding Fee, Borrow Fee, phần chia lợi nhuận từ Hyper Lev, các khoản phí gửi/rút của Pool hoặc Vault và Gas.
Ví dụ giả định: Nếu một lượt giao dịch tạo ra 20 USD phí mở/đóng đáp ứng điều kiện, thì khoản tiết kiệm từ giảm 5% là 1 USD. Nhưng nếu để nâng cấp hạng giới thiệu mà thường xuyên mở/đóng vị thế, phát sinh thêm trượt giá, phí lãi suất cho vốn và các giao dịch sai lầm, thì có thể vượt xa con số 1 USD này.
Hạng của người giới thiệu cũng dựa trên số lượng người dùng hoạt động và tổng khối lượng giao dịch trong 30 ngày gần nhất. Trong đó, khối lượng giao dịch được tính theo vị thế danh nghĩa, không phải số tiền ký quỹ thực tế mà người dùng đã nạp. Vì vậy, giao dịch để tăng khối lượng bằng đòn bẩy cao không làm rủi ro biến mất; trái lại, có thể khiến người đó phải gánh tổn thất thanh lý lớn hơn để đổi lấy phần hoàn tiền.
Về an toàn cũng cần lưu ý: liên kết mã giới thiệu không cần chuyển tiền cho người giới thiệu, cũng không cần cung cấp khóa cá nhân hay cụm từ ghi nhớ. Trước khi ký bằng ví, hãy kiểm tra tên miền của trang web chính thức, mạng và nội dung cấp quyền cụ thể.
Hiện tại, cũng không thể hiểu trực tiếp quan hệ giới thiệu như việc đã xác nhận token hay suất đầu tư. Thu nhập từ giới thiệu đến từ các khoản phí phát sinh từ giao dịch thực tế; còn việc trong tương lai có kết nối thêm các quyền đối với token khác hay không vẫn phải chờ quy tắc chính thức.
Một cơ chế giới thiệu tốt cần làm giảm chi phí giao dịch thực sự của người dùng, thay vì khiến mọi người tạo ra các giao dịch không cần thiết chỉ để nhận thưởng.
Đăng nhập để khám phá thêm nội dung
Tham gia cùng người dùng tiền mã hóa toàn cầu trên Binance Square
⚡️ Nhận thông tin mới nhất và hữu ích về tiền mã hóa.
💬 Được tin cậy bởi sàn giao dịch tiền mã hóa lớn nhất thế giới.
👍 Khám phá những thông tin chuyên sâu thực tế từ những nhà sáng tạo đã xác minh.