Binance Square
Retsu玄
3.8k Bài đăng

Retsu玄

I write about crypto as systems, not stories
Giao dịch mở
Trader thường xuyên
{thời gian} năm
478 Đang theo dõi
18.3K+ Người theo dõi
5.6K+ Đã thích
Bài đăng
Danh mục đầu tư
·
--
Xem bản dịch
#dusk $DUSK @Dusk_Foundation After reviewing Dusk’s staking materials I noticed that the real constraint has never been the absolute size of a stake so much as the operational burden of keeping a provisioner online and synchronized. Hyperstaking simply relocates that burden from an individual operator to a smart-contract layer that can hold positions, collect rewards, and allocate them according to programmable rules. In practice the mechanism works by letting capital first enter a pool; the pool then calls the Transfer Contract’s stake_from_contract function to create the position. Later the Stake Contract notifies the same pool when rewards become claimable or when an unstake is requested, so the contract itself becomes the active manager of the stake. The 1000 DUSK minimum and the roughly 4320-block maturation window still apply, whether the caller is a human or a contract. The difficulty appears once the pool sits between the protocol and the end user. Exit liquidity can be throttled by the pool’s own queue, fee schedule, or internal accounting, even though the base chain itself imposes no unbonding delay. Users also inherit exposure to share-calculation errors, callback failures, reward-distribution logic, and any upgrade keys the contract may hold. What looks like the removal of a custodial node is therefore only a shift of the control surface one layer higher. Still, the design is worth watching because it opens a path for capital strategies that run continuously rather than as discrete user actions. If the pool contracts prove open, auditable, and able to reconcile every token movement on-chain, the same machinery that currently feels opaque could become a durable primitive for coordinated participation.
#dusk $DUSK @Dusk
After reviewing Dusk’s staking materials I noticed that the real constraint has never been the absolute size of a stake so much as the operational burden of keeping a provisioner online and synchronized. Hyperstaking simply relocates that burden from an individual operator to a smart-contract layer that can hold positions, collect rewards, and allocate them according to programmable rules.

In practice the mechanism works by letting capital first enter a pool; the pool then calls the Transfer Contract’s stake_from_contract function to create the position. Later the Stake Contract notifies the same pool when rewards become claimable or when an unstake is requested, so the contract itself becomes the active manager of the stake. The 1000 DUSK minimum and the roughly 4320-block maturation window still apply, whether the caller is a human or a contract.

The difficulty appears once the pool sits between the protocol and the end user. Exit liquidity can be throttled by the pool’s own queue, fee schedule, or internal accounting, even though the base chain itself imposes no unbonding delay. Users also inherit exposure to share-calculation errors, callback failures, reward-distribution logic, and any upgrade keys the contract may hold. What looks like the removal of a custodial node is therefore only a shift of the control surface one layer higher.

Still, the design is worth watching because it opens a path for capital strategies that run continuously rather than as discrete user actions. If the pool contracts prove open, auditable, and able to reconcile every token movement on-chain, the same machinery that currently feels opaque could become a durable primitive for coordinated participation.
Đã xác minh
Tôi quay lại các trang sản phẩm hiện tại của Dusk và tự bắt gặp mình đang đưa ra một giả định khá rộng: vì mainnet đã hoạt động, tôi đã coi toàn bộ ngăn xếp tài chính như thể đã đi đến cùng một giai đoạn. Những nhãn trạng thái đã làm thay đổi nhận định đó. Dusk L1 đã hoạt động, cung cấp sự đồng thuận (consensus), quyết toán (settlement), sẵn có dữ liệu (data availability), các giao dịch công khai và được che chắn (shielded), cùng với việc thực thi DuskVM. DuskEVM vẫn đang ở testnet, nơi các ứng dụng Solidity sử dụng công cụ EVM quen thuộc và DUSK cho gas, nhưng việc quyết toán diễn ra thông qua DuskDS. Bộ phòng hộ (hedger) cũng đang ở testnet, bổ sung các luồng EVM mang tính bảo mật. Dusk Trade vẫn đang được xây dựng như lớp sản phẩm cho việc giới thiệu người dùng (onboarding), kiểm soát truy cập, giao dịch, điều phối thanh toán và quyết toán. Điều đó khiến tôi nhìn nhận khác đi. Cách hiểu của tôi: Dusk có một nền tảng (base) đã hoạt động, nhưng luận điểm tài chính tổng thể của họ phụ thuộc vào nhiều lớp đang chuyển động để cùng sẵn sàng cho sản xuất. Một L1 an toàn không tự động chứng minh rằng lớp EVM, engine quyền riêng tư, cầu nối (bridge) và ứng dụng người dùng sẽ vận hành như một quy trình thị trường đáng tin cậy. Điểm chưa chắc của tôi là rủi ro tích hợp. Những điều kiện phát hành và kiểm toán nào sẽ đưa DuskEVM và Hedger từ testnet sang mainnet? Nếu Dusk Trade phụ thuộc vào các lớp đó, thì việc nâng cấp hoặc các sự cố sẽ được phối hợp như thế nào mà không làm gián đoạn khả năng đủ điều kiện (eligibility), giao dịch hay quyết toán? Tôi muốn theo dõi điều này trong thực tế. #dusk $DUSK @Dusk_Foundation
Tôi quay lại các trang sản phẩm hiện tại của Dusk và tự bắt gặp mình đang đưa ra một giả định khá rộng: vì mainnet đã hoạt động, tôi đã coi toàn bộ ngăn xếp tài chính như thể đã đi đến cùng một giai đoạn. Những nhãn trạng thái đã làm thay đổi nhận định đó.

Dusk L1 đã hoạt động, cung cấp sự đồng thuận (consensus), quyết toán (settlement), sẵn có dữ liệu (data availability), các giao dịch công khai và được che chắn (shielded), cùng với việc thực thi DuskVM. DuskEVM vẫn đang ở testnet, nơi các ứng dụng Solidity sử dụng công cụ EVM quen thuộc và DUSK cho gas, nhưng việc quyết toán diễn ra thông qua DuskDS. Bộ phòng hộ (hedger) cũng đang ở testnet, bổ sung các luồng EVM mang tính bảo mật. Dusk Trade vẫn đang được xây dựng như lớp sản phẩm cho việc giới thiệu người dùng (onboarding), kiểm soát truy cập, giao dịch, điều phối thanh toán và quyết toán.

Điều đó khiến tôi nhìn nhận khác đi.

Cách hiểu của tôi: Dusk có một nền tảng (base) đã hoạt động, nhưng luận điểm tài chính tổng thể của họ phụ thuộc vào nhiều lớp đang chuyển động để cùng sẵn sàng cho sản xuất. Một L1 an toàn không tự động chứng minh rằng lớp EVM, engine quyền riêng tư, cầu nối (bridge) và ứng dụng người dùng sẽ vận hành như một quy trình thị trường đáng tin cậy.

Điểm chưa chắc của tôi là rủi ro tích hợp. Những điều kiện phát hành và kiểm toán nào sẽ đưa DuskEVM và Hedger từ testnet sang mainnet? Nếu Dusk Trade phụ thuộc vào các lớp đó, thì việc nâng cấp hoặc các sự cố sẽ được phối hợp như thế nào mà không làm gián đoạn khả năng đủ điều kiện (eligibility), giao dịch hay quyết toán?

Tôi muốn theo dõi điều này trong thực tế.

#dusk $DUSK @Dusk
Đã xác minh
Mình sẽ nói thẳng ở đây: điều khiến mình chú ý về DuskEVM không phải là khả năng tương thích với EVM một cách thuần túy, mà là cách khả năng đó có thể mở rộng giá trị sử dụng thực sự cho Dusk. Hiện tại, DuskEVM đang ở giai đoạn testnet. Nó cung cấp cho các nhà phát triển Solidity những ví, thư viện, Foundry và Hardhat quen thuộc, với DUSK được dùng làm token gas gốc. Các giao dịch được thực thi trên DuskEVM, trong khi các batch và cam kết trạng thái được công bố lên DuskDS để phục vụ tính sẵn có dữ liệu và thanh toán/quyết toán. Trên thực tế, việc giảm “ma sát” khi dùng công cụ có thể thu hút nhiều nhà xây dựng hơn; các ứng dụng hữu ích có thể tạo ra nhiều giao dịch hơn; và những giao dịch đó cần DUSK để thực thi. Ngoài ra, việc staking DUSK giúp bảo đảm an toàn cho toàn bộ mạng Dusk. Tuy nhiên, khả năng tương thích không tự động tạo ra thanh khoản cho DEX, nhu cầu vay mượn, TVL hay doanh thu. Các nhà xây dựng vẫn cần hạ tầng đáng tin cậy và những sản phẩm mà người dùng sẵn sàng quay lại. Đây là lúc Dusk Trade phù hợp với chiến lược: nó đang được xây dựng như lớp ứng dụng cho các tài sản tài chính được token hóa, kết nối các mảng từ onboarding, giao dịch, điều phối thanh toán và thanh toán/quyết toán. Quan điểm của mình khá đơn giản: tiện ích của DUSK chỉ thật sự trở nên có ý nghĩa khi quá trình phát triển ở testnet chuyển thành việc sử dụng lặp lại trên mainnet. Cơ chế có thể hỗ trợ nhu cầu, nhưng việc được áp dụng vẫn phải giành được. #dusk $DUSK @Dusk_Foundation
Mình sẽ nói thẳng ở đây: điều khiến mình chú ý về DuskEVM không phải là khả năng tương thích với EVM một cách thuần túy, mà là cách khả năng đó có thể mở rộng giá trị sử dụng thực sự cho Dusk.

Hiện tại, DuskEVM đang ở giai đoạn testnet. Nó cung cấp cho các nhà phát triển Solidity những ví, thư viện, Foundry và Hardhat quen thuộc, với DUSK được dùng làm token gas gốc. Các giao dịch được thực thi trên DuskEVM, trong khi các batch và cam kết trạng thái được công bố lên DuskDS để phục vụ tính sẵn có dữ liệu và thanh toán/quyết toán. Trên thực tế, việc giảm “ma sát” khi dùng công cụ có thể thu hút nhiều nhà xây dựng hơn; các ứng dụng hữu ích có thể tạo ra nhiều giao dịch hơn; và những giao dịch đó cần DUSK để thực thi. Ngoài ra, việc staking DUSK giúp bảo đảm an toàn cho toàn bộ mạng Dusk.

Tuy nhiên, khả năng tương thích không tự động tạo ra thanh khoản cho DEX, nhu cầu vay mượn, TVL hay doanh thu. Các nhà xây dựng vẫn cần hạ tầng đáng tin cậy và những sản phẩm mà người dùng sẵn sàng quay lại. Đây là lúc Dusk Trade phù hợp với chiến lược: nó đang được xây dựng như lớp ứng dụng cho các tài sản tài chính được token hóa, kết nối các mảng từ onboarding, giao dịch, điều phối thanh toán và thanh toán/quyết toán.

Quan điểm của mình khá đơn giản: tiện ích của DUSK chỉ thật sự trở nên có ý nghĩa khi quá trình phát triển ở testnet chuyển thành việc sử dụng lặp lại trên mainnet. Cơ chế có thể hỗ trợ nhu cầu, nhưng việc được áp dụng vẫn phải giành được.

#dusk $DUSK @Dusk
#dusk $DUSK Tối qua tôi đã xem lại tài liệu @Dusk_Foundation , và tôi bắt gặp mình đã coi “finalized” như thể là một khoảnh khắc duy nhất. Tôi cho rằng khi một giao dịch Dusk được final thì tiền sẽ ngay lập tức tồn tại trên DuskEVM. Tài liệu cũng khiến giả định đó có vẻ quá đơn giản. Trên DuskEVM Testnet, một khoản tiền gửi được gửi và được finalized trên Dusk L1, sau đó được xử lý trước khi số dư trở nên khả dụng trên DuskEVM. Việc rút tiền có nhiều giai đoạn hơn: khởi tạo trên DuskEVM, chờ một output, prove trên Dusk L1, vượt qua các bài kiểm tra maturity và dispute-game bắt buộc, rồi mới finalize trên L1. Tài liệu cảnh báo rằng việc inclusion, execution và finality không phải là cùng một trạng thái, và mức “sẵn sàng” nên dựa trên trạng thái của giao thức chứ không phải dựa trên thời gian trôi qua. Điều đó khiến tôi nhìn nhận theo cách khác. Cách hiểu của tôi: cầu nối không phải là một kiểu trì hoãn để che giấu; nó đang cố biến một máy trạng thái xuyên lớp thành thứ mà ví có thể giải thích. Mâu thuẫn nằm ở chỗ cân bằng giữa bảo mật và sự phụ thuộc vận hành. Những lần thử lại an toàn hơn, khả năng khôi phục khi rollback, và các kiểm tra challenge sẽ giảm một nhóm rủi ro, nhưng các đường phục hồi cũng đồng thời dồn trách nhiệm vào một nơi nào đó. Sự không chắc chắn của tôi: trong trường hợp rollback kèm thất bại của relayer, người dùng có thể tự kiểm chứng độc lập điều gì trước khi tiền được phát hành hoặc được thử lại? Ai có thể tạm dừng hoặc tiếp tục vận hành cầu nối, và quyền hạn đó bị giới hạn như thế nào nếu tình trạng khẩn cấp kéo dài hơn dự kiến? Tôi muốn theo dõi điều này trong thực tế.
#dusk $DUSK
Tối qua tôi đã xem lại tài liệu @Dusk , và tôi bắt gặp mình đã coi “finalized” như thể là một khoảnh khắc duy nhất. Tôi cho rằng khi một giao dịch Dusk được final thì tiền sẽ ngay lập tức tồn tại trên DuskEVM. Tài liệu cũng khiến giả định đó có vẻ quá đơn giản.

Trên DuskEVM Testnet, một khoản tiền gửi được gửi và được finalized trên Dusk L1, sau đó được xử lý trước khi số dư trở nên khả dụng trên DuskEVM. Việc rút tiền có nhiều giai đoạn hơn: khởi tạo trên DuskEVM, chờ một output, prove trên Dusk L1, vượt qua các bài kiểm tra maturity và dispute-game bắt buộc, rồi mới finalize trên L1. Tài liệu cảnh báo rằng việc inclusion, execution và finality không phải là cùng một trạng thái, và mức “sẵn sàng” nên dựa trên trạng thái của giao thức chứ không phải dựa trên thời gian trôi qua.

Điều đó khiến tôi nhìn nhận theo cách khác.

Cách hiểu của tôi: cầu nối không phải là một kiểu trì hoãn để che giấu; nó đang cố biến một máy trạng thái xuyên lớp thành thứ mà ví có thể giải thích. Mâu thuẫn nằm ở chỗ cân bằng giữa bảo mật và sự phụ thuộc vận hành. Những lần thử lại an toàn hơn, khả năng khôi phục khi rollback, và các kiểm tra challenge sẽ giảm một nhóm rủi ro, nhưng các đường phục hồi cũng đồng thời dồn trách nhiệm vào một nơi nào đó.

Sự không chắc chắn của tôi: trong trường hợp rollback kèm thất bại của relayer, người dùng có thể tự kiểm chứng độc lập điều gì trước khi tiền được phát hành hoặc được thử lại? Ai có thể tạm dừng hoặc tiếp tục vận hành cầu nối, và quyền hạn đó bị giới hạn như thế nào nếu tình trạng khẩn cấp kéo dài hơn dự kiến?

Tôi muốn theo dõi điều này trong thực tế.
#termmax @termmax Tối qua tôi xem lại tài liệu TermMax với một cách hiểu ban đầu: lãi suất cố định của nó chủ yếu đến từ việc khóa một khoản vay cho đến khi đáo hạn. Cơ chế vận hành đã làm thay đổi quan điểm đó. FT là một tài sản có thể thay thế (fungible) theo chuẩn ERC-20, có thể được đổi lấy một token nợ tại thời điểm đáo hạn. XT là phần bù có thể thay thế của nó: 1 FT cộng 1 XT bằng đúng một token nợ, và XT sẽ về 0 tại đáo hạn. GT là một vị thế ERC-721 ghi nhận tài sản thế chấp và nợ của từng khoản vay. FT cũng có thể được bán trước khi đáo hạn theo mức giá và thanh khoản sẵn có tại thời điểm đó. Lệnh theo dải (range order) là một chuỗi các lệnh liên tục do một setter hoặc curator cấu hình. Đường cong định giá phân đoạn của nó phân bổ thanh khoản qua các dải APR, vì vậy mức lãi suất mà bên mua thị trường (taker) nhận được sẽ thay đổi khi các giao dịch đi qua đường cong. Điều đó khiến tôi nhìn nhận khác đi. Hợp đồng lệnh V2 đưa số ngày còn lại đến đáo hạn vào phép tính APR thông qua các “dự trữ ảo” của đường cong. Cách hiểu của tôi là TermMax không chỉ khóa một mức lãi suất: nó tạo ra một thị trường nơi thời gian, cách đặt thanh khoản và việc thực thi định hình cách mức lãi suất đó được xác định. Việc thoát lệnh của FT sẽ được thực hiện như thế nào khi thanh khoản mỏng dần và người bán đến cùng lúc? Các lệnh có thể tập trung đến mức nào trong một phân đoạn của đường cong, và mức độ phân tán quyền kiểm soát đối với các tham số đường cong cũng như rủi ro ra sao? Tôi cũng muốn xem sự phụ thuộc vào oracle và hành vi thanh lý diễn ra như thế nào trong điều kiện căng thẳng. Tôi muốn quan sát điều này trong thực tế.
#termmax @TermMax

Tối qua tôi xem lại tài liệu TermMax với một cách hiểu ban đầu: lãi suất cố định của nó chủ yếu đến từ việc khóa một khoản vay cho đến khi đáo hạn. Cơ chế vận hành đã làm thay đổi quan điểm đó.

FT là một tài sản có thể thay thế (fungible) theo chuẩn ERC-20, có thể được đổi lấy một token nợ tại thời điểm đáo hạn. XT là phần bù có thể thay thế của nó: 1 FT cộng 1 XT bằng đúng một token nợ, và XT sẽ về 0 tại đáo hạn. GT là một vị thế ERC-721 ghi nhận tài sản thế chấp và nợ của từng khoản vay. FT cũng có thể được bán trước khi đáo hạn theo mức giá và thanh khoản sẵn có tại thời điểm đó.

Lệnh theo dải (range order) là một chuỗi các lệnh liên tục do một setter hoặc curator cấu hình. Đường cong định giá phân đoạn của nó phân bổ thanh khoản qua các dải APR, vì vậy mức lãi suất mà bên mua thị trường (taker) nhận được sẽ thay đổi khi các giao dịch đi qua đường cong.

Điều đó khiến tôi nhìn nhận khác đi.

Hợp đồng lệnh V2 đưa số ngày còn lại đến đáo hạn vào phép tính APR thông qua các “dự trữ ảo” của đường cong. Cách hiểu của tôi là TermMax không chỉ khóa một mức lãi suất: nó tạo ra một thị trường nơi thời gian, cách đặt thanh khoản và việc thực thi định hình cách mức lãi suất đó được xác định.

Việc thoát lệnh của FT sẽ được thực hiện như thế nào khi thanh khoản mỏng dần và người bán đến cùng lúc? Các lệnh có thể tập trung đến mức nào trong một phân đoạn của đường cong, và mức độ phân tán quyền kiểm soát đối với các tham số đường cong cũng như rủi ro ra sao? Tôi cũng muốn xem sự phụ thuộc vào oracle và hành vi thanh lý diễn ra như thế nào trong điều kiện căng thẳng.

Tôi muốn quan sát điều này trong thực tế.
#dusk $DUSK @Dusk_Foundation Ban đầu, tôi tiếp cận tài liệu của Dusk với một hiểu biết đơn giản: việc token hóa một trái phiếu hay quỹ chủ yếu là ghi nhận quyền sở hữu trong một hợp đồng thông minh. Điều làm thay đổi góc nhìn của tôi là nhận ra rằng độ phức tạp thực sự nằm ở hệ sinh thái bao quanh token — các quy tắc về tính đủ điều kiện, chuyển nhượng, xử lý dữ liệu riêng tư, thanh toán, quyết toán và việc vận hành/duy trì liên tục đều cần phải được đồng bộ. Dusk giải quyết điều đó bằng cách phân chia trách nhiệm trên kiến trúc của mình. DuskVM thực thi trực tiếp các hợp đồng viết bằng Rust và WebAssembly trên Layer 1. DuskEVM cho phép các ứng dụng dựa trên Solidity tận dụng các công cụ EVM quen thuộc, trong khi các lô giao dịch (batches), siêu dữ liệu giao dịch và các cam kết trạng thái tiến dần đến quyết toán cuối cùng thông qua DuskDS. Citadel sử dụng thông tin xác thực (credentials) và các bằng chứng không kiến thức (zero-knowledge proofs) để người dùng có thể chứng minh rằng họ sở hữu một giấy phép đã được chấp thuận mà không tiết lộ thông tin cá nhân hoặc toàn bộ chi tiết giấy phép trên chuỗi; các nhà cung cấp dịch vụ vẫn giữ quyền kiểm soát việc họ công nhận những tổ chức phát hành (issuers) và thuộc tính nào. Điều này đã thay đổi cách tôi nhìn nhận hệ thống. Bài học rút ra của tôi: quyền riêng tư ở đây không phải là nhằm đảm bảo mọi thứ hoàn toàn vô hình. Mục tiêu là cho phép xác minh mà không cần phải tiết lộ rộng rãi. Tuy nhiên, thách thức là xác định quyền kiểm soát nằm ở đâu khi các ranh giới này trở nên quan trọng. Nếu một thông tin xác thực bị thu hồi ngay giữa giao dịch, thì trạng thái nào sẽ chi phối tính đủ điều kiện tại thời điểm quyết toán? Và khi các chính sách từ tổ chức phát hành, sàn giao dịch, bên kiểm toán và cơ quan quản lý xung đột với nhau, thì rốt cuộc ai là người quyết định khi nào và phải tiết lộ bao nhiêu thông tin? Tôi rất háo hức xem điều này sẽ diễn ra như thế nào trong các tình huống sử dụng thực tế.
#dusk $DUSK @Dusk
Ban đầu, tôi tiếp cận tài liệu của Dusk với một hiểu biết đơn giản: việc token hóa một trái phiếu hay quỹ chủ yếu là ghi nhận quyền sở hữu trong một hợp đồng thông minh. Điều làm thay đổi góc nhìn của tôi là nhận ra rằng độ phức tạp thực sự nằm ở hệ sinh thái bao quanh token — các quy tắc về tính đủ điều kiện, chuyển nhượng, xử lý dữ liệu riêng tư, thanh toán, quyết toán và việc vận hành/duy trì liên tục đều cần phải được đồng bộ.

Dusk giải quyết điều đó bằng cách phân chia trách nhiệm trên kiến trúc của mình. DuskVM thực thi trực tiếp các hợp đồng viết bằng Rust và WebAssembly trên Layer 1. DuskEVM cho phép các ứng dụng dựa trên Solidity tận dụng các công cụ EVM quen thuộc, trong khi các lô giao dịch (batches), siêu dữ liệu giao dịch và các cam kết trạng thái tiến dần đến quyết toán cuối cùng thông qua DuskDS. Citadel sử dụng thông tin xác thực (credentials) và các bằng chứng không kiến thức (zero-knowledge proofs) để người dùng có thể chứng minh rằng họ sở hữu một giấy phép đã được chấp thuận mà không tiết lộ thông tin cá nhân hoặc toàn bộ chi tiết giấy phép trên chuỗi; các nhà cung cấp dịch vụ vẫn giữ quyền kiểm soát việc họ công nhận những tổ chức phát hành (issuers) và thuộc tính nào.

Điều này đã thay đổi cách tôi nhìn nhận hệ thống.

Bài học rút ra của tôi: quyền riêng tư ở đây không phải là nhằm đảm bảo mọi thứ hoàn toàn vô hình. Mục tiêu là cho phép xác minh mà không cần phải tiết lộ rộng rãi. Tuy nhiên, thách thức là xác định quyền kiểm soát nằm ở đâu khi các ranh giới này trở nên quan trọng. Nếu một thông tin xác thực bị thu hồi ngay giữa giao dịch, thì trạng thái nào sẽ chi phối tính đủ điều kiện tại thời điểm quyết toán? Và khi các chính sách từ tổ chức phát hành, sàn giao dịch, bên kiểm toán và cơ quan quản lý xung đột với nhau, thì rốt cuộc ai là người quyết định khi nào và phải tiết lộ bao nhiêu thông tin?

Tôi rất háo hức xem điều này sẽ diễn ra như thế nào trong các tình huống sử dụng thực tế.
#termmax @termmax Tôi đã dành một phần đêm qua để lần theo một thị trường TermMax từ tài liệu vào trong mã hợp đồng. Ban đầu tôi hiểu rằng FT, XT và GT là ba nhãn cho cùng một khoản vay. FT là một ERC-20 được mua dưới mệnh giá, được hoàn trả theo mệnh giá trong token nợ khi đáo hạn, và có thể giao dịch trước thời điểm đó. XT là một ERC-20 đại diện cho nghĩa vụ lãi suất; giá trị hiện tại kết hợp của FT và XT bằng với số tiền cho vay ban đầu. GT là một ERC-721 đại diện cho vị thế vay và ghi lại tài sản thế chấp cũng như khoản nợ. Một lệnh theo dải (range order) là một chuỗi các lệnh liên tục được cấu hình bởi một setter hoặc curator. Đường cong giá của nó được xây dựng từ các đoạn với giới hạn APR phía trên và giới hạn XT phía dưới, và một thị trường có thể chứa nhiều lệnh theo dải. Điều đó khiến tôi nhìn nhận khác đi. Bản whitepaper định nghĩa tỷ lệ thời gian của nó là số ngày đến đáo hạn chia cho 365. Các hợp đồng V2 tính toán số ngày còn lại và truyền giá trị đó vào trong logic của đường cong và hoán đổi FT/XT. Cách tôi hiểu là lãi suất mà người dùng thấy phản ánh vị trí của đường cong, biến động dự trữ XT và thời gian. Điều gì xảy ra với lối thoát của một FT khi thanh khoản chỉ nằm trong vài đoạn? Trong giai đoạn thị trường căng thẳng, cơ chế dự phòng oracle, trượt giá trên DEX, và năng lực thanh lý tương tác với nhau như thế nào? Nên phân chia quyền kiểm soát giữa các curator, guardian, admin và quản trị token ra sao? Tôi muốn theo dõi điều này trong thực tế.
#termmax @TermMax

Tôi đã dành một phần đêm qua để lần theo một thị trường TermMax từ tài liệu vào trong mã hợp đồng. Ban đầu tôi hiểu rằng FT, XT và GT là ba nhãn cho cùng một khoản vay. FT là một ERC-20 được mua dưới mệnh giá, được hoàn trả theo mệnh giá trong token nợ khi đáo hạn, và có thể giao dịch trước thời điểm đó. XT là một ERC-20 đại diện cho nghĩa vụ lãi suất; giá trị hiện tại kết hợp của FT và XT bằng với số tiền cho vay ban đầu. GT là một ERC-721 đại diện cho vị thế vay và ghi lại tài sản thế chấp cũng như khoản nợ.

Một lệnh theo dải (range order) là một chuỗi các lệnh liên tục được cấu hình bởi một setter hoặc curator. Đường cong giá của nó được xây dựng từ các đoạn với giới hạn APR phía trên và giới hạn XT phía dưới, và một thị trường có thể chứa nhiều lệnh theo dải.

Điều đó khiến tôi nhìn nhận khác đi.

Bản whitepaper định nghĩa tỷ lệ thời gian của nó là số ngày đến đáo hạn chia cho 365. Các hợp đồng V2 tính toán số ngày còn lại và truyền giá trị đó vào trong logic của đường cong và hoán đổi FT/XT.

Cách tôi hiểu là lãi suất mà người dùng thấy phản ánh vị trí của đường cong, biến động dự trữ XT và thời gian. Điều gì xảy ra với lối thoát của một FT khi thanh khoản chỉ nằm trong vài đoạn? Trong giai đoạn thị trường căng thẳng, cơ chế dự phòng oracle, trượt giá trên DEX, và năng lực thanh lý tương tác với nhau như thế nào? Nên phân chia quyền kiểm soát giữa các curator, guardian, admin và quản trị token ra sao?

Tôi muốn theo dõi điều này trong thực tế.
#termmax @termmax Tôi đã dành nhiều năm quan sát DeFi và cuộc truy đuổi lợi suất của nó, và tôi thấy lời hứa của các thị trường lãi suất cố định rất hấp dẫn. Tôi đã chứng kiến quá nhiều chu kỳ mà lời hứa về tiền dễ dàng lại phải đánh đổi bằng điều gì đó lớn hơn: một token zero-coupon xác định một quyền yêu cầu tại thời điểm đáo hạn, chứ không phải một lối thoát dễ dàng hiện thực hóa. Thiết kế của TermMax khiến tôi chú ý trong bối cảnh lệnh giới hạn theo biên (range orders), việc báo giá một mức lãi suất theo một đường cong, và các lệnh nguyên tử (atomic orders) trải qua nhiều thị trường bằng cách chia sẻ một pool, nỗ lực của Smart Unwind trong việc tìm kiếm thanh khoản để đóng một vị thế nợ, cùng với thách thức của sự phân mảnh giữa tài sản thế chấp và các kỳ hạn. Mỗi yếu tố thiết kế này đều giải quyết rủi ro thanh khoản kém khi thoát lệnh, nhưng đi kèm với cái giá là tính sẵn có của thanh khoản tại bất kỳ thời điểm nào bị giảm xuống. Nhu cầu về một đối tác mua nghĩa vụ tại bất kỳ thời điểm nào vẫn tồn tại, và đối tác đó có thể không phải lúc nào cũng sẵn sàng, dẫn đến trượt giá, chậm trễ, hoặc thậm chí là không có thị trường hoàn toàn. Tài liệu Alpha của TermMax thừa nhận điều này khi nêu rằng thanh khoản không được đảm bảo. Tôi tự hỏi liệu lời hứa của việc cho vay lãi suất cố định có thực sự không phải là nguồn gốc của nguy cơ hay không—nó chỉ đơn giản là chuyển bài toán sang nơi khác. Việc giao tài sản thế chấp mang tính vật chất là nền tảng của mọi nghĩa vụ, nhưng giá trị của tài sản thế chấp có thể thấp hơn giá trị của khoản nợ phải trả nếu bên cho vay không thể giao đúng tài sản cụ thể đã hứa vào thời điểm thanh lý. Các cuộc kiểm toán, mã nguồn mở và chương trình bounty đều rất hữu ích, nhưng chúng không loại bỏ được rủi ro hợp đồng thất bại, oracle (nguồn dữ liệu), hoặc sự phân mảnh của thị trường. Bằng cách cố định lãi suất, TermMax giảm rủi ro biến động lãi suất (rate shocks) nhưng không giảm rủi ro biến động thanh khoản (liquidity shocks). Đây là sự đánh đổi mà tôi sẵn sàng chấp nhận vì mục tiêu lợi suất.
#termmax @TermMax
Tôi đã dành nhiều năm quan sát DeFi và cuộc truy đuổi lợi suất của nó, và tôi thấy lời hứa của các thị trường lãi suất cố định rất hấp dẫn. Tôi đã chứng kiến quá nhiều chu kỳ mà lời hứa về tiền dễ dàng lại phải đánh đổi bằng điều gì đó lớn hơn: một token zero-coupon xác định một quyền yêu cầu tại thời điểm đáo hạn, chứ không phải một lối thoát dễ dàng hiện thực hóa.

Thiết kế của TermMax khiến tôi chú ý trong bối cảnh lệnh giới hạn theo biên (range orders), việc báo giá một mức lãi suất theo một đường cong, và các lệnh nguyên tử (atomic orders) trải qua nhiều thị trường bằng cách chia sẻ một pool, nỗ lực của Smart Unwind trong việc tìm kiếm thanh khoản để đóng một vị thế nợ, cùng với thách thức của sự phân mảnh giữa tài sản thế chấp và các kỳ hạn. Mỗi yếu tố thiết kế này đều giải quyết rủi ro thanh khoản kém khi thoát lệnh, nhưng đi kèm với cái giá là tính sẵn có của thanh khoản tại bất kỳ thời điểm nào bị giảm xuống. Nhu cầu về một đối tác mua nghĩa vụ tại bất kỳ thời điểm nào vẫn tồn tại, và đối tác đó có thể không phải lúc nào cũng sẵn sàng, dẫn đến trượt giá, chậm trễ, hoặc thậm chí là không có thị trường hoàn toàn. Tài liệu Alpha của TermMax thừa nhận điều này khi nêu rằng thanh khoản không được đảm bảo.

Tôi tự hỏi liệu lời hứa của việc cho vay lãi suất cố định có thực sự không phải là nguồn gốc của nguy cơ hay không—nó chỉ đơn giản là chuyển bài toán sang nơi khác. Việc giao tài sản thế chấp mang tính vật chất là nền tảng của mọi nghĩa vụ, nhưng giá trị của tài sản thế chấp có thể thấp hơn giá trị của khoản nợ phải trả nếu bên cho vay không thể giao đúng tài sản cụ thể đã hứa vào thời điểm thanh lý. Các cuộc kiểm toán, mã nguồn mở và chương trình bounty đều rất hữu ích, nhưng chúng không loại bỏ được rủi ro hợp đồng thất bại, oracle (nguồn dữ liệu), hoặc sự phân mảnh của thị trường. Bằng cách cố định lãi suất, TermMax giảm rủi ro biến động lãi suất (rate shocks) nhưng không giảm rủi ro biến động thanh khoản (liquidity shocks). Đây là sự đánh đổi mà tôi sẵn sàng chấp nhận vì mục tiêu lợi suất.
Đêm qua, tôi đã xem lại tài liệu Dusk, tập trung vào việc nắm bắt vai trò thực sự $DUSK plays trong giao thức—chức năng kỹ thuật của nó chứ không phải câu chuyện do thị trường dẫn dắt. Điều đầu tiên tôi phải gỡ rối là hai mô hình giao dịch của DuskDS. Moonlight là lộ trình quen thuộc: tài khoản công khai, số dư hiển thị, người gửi, người nhận, số tiền. Phoenix hoạt động với các “notes” được mã hóa. Để chi tiêu một note, người dùng cung cấp một bằng chứng không kiến thức (zero-knowledge proof) chứng minh rằng quyền sở hữu và các quy tắc về số dư đều được thỏa mãn. Hãy tưởng tượng bạn đưa cho một nhân viên một phong bì được niêm phong, trong đó con dấu chứng minh rằng mọi ô cần thiết đã được kiểm tra, mà không tiết lộ nội dung bên trong. Sau đó, nullifier giúp mạng từ chối một lần chi tiêu thứ hai mà không phải xác định note nào trong cây công khai đã được dùng. Tôi đã đọc lại đoạn đó hai lần—rồi một thông báo kéo tôi ra khỏi nó—bởi vì “riêng tư” không có nghĩa là “không có gì được kiểm tra”. Nó có nghĩa là mạng kiểm tra một bằng chứng thay vì các chi tiết giao dịch bị che giấu. Các viewing key có thể được dùng để tiết lộ thông tin một cách chọn lọc. Việc đạt đồng thuận cũng cần thêm một lượt xem. Dusk gọi đó là Succinct Attestation (Xác thực gọn nhẹ): các staker, hay provisioners, khóa DUSK; việc chọn proposer theo tỷ trọng stake và xác định trước sẽ xác định người đề xuất một block, sau đó một ủy ban sẽ xác thực và một ủy ban khác phê chuẩn. Các chữ ký gộp lại trở thành một bản attestation rằng một quorum đã đồng ý. Vì vậy $DUSK vừa là gas vừa là phần stake đứng sau sự tham gia. Phần tôi sẽ xem tiếp theo là mức độ tập trung. Việc chọn người là không cần xin phép, nhưng trong thực tế, mức độ phân tán của các “committee credits” hiệu quả ra sao? Trong những trang tôi đọc, tôi không tìm thấy một bản tường thuật rõ ràng về việc ai thay đổi các tham số toàn cục—có thể tôi đã bỏ sót. Những bằng chứng nào sẽ cho thấy quyền lực của ủy ban thực sự được phân tán? Các viewing keys được quản trị thế nào trong các triển khai thực tế? Ai có thể thay đổi tham số giao thức, và theo quy trình nào? #dusk $DUSK @Dusk_Foundation
Đêm qua, tôi đã xem lại tài liệu Dusk, tập trung vào việc nắm bắt vai trò thực sự $DUSK plays trong giao thức—chức năng kỹ thuật của nó chứ không phải câu chuyện do thị trường dẫn dắt.

Điều đầu tiên tôi phải gỡ rối là hai mô hình giao dịch của DuskDS. Moonlight là lộ trình quen thuộc: tài khoản công khai, số dư hiển thị, người gửi, người nhận, số tiền. Phoenix hoạt động với các “notes” được mã hóa. Để chi tiêu một note, người dùng cung cấp một bằng chứng không kiến thức (zero-knowledge proof) chứng minh rằng quyền sở hữu và các quy tắc về số dư đều được thỏa mãn. Hãy tưởng tượng bạn đưa cho một nhân viên một phong bì được niêm phong, trong đó con dấu chứng minh rằng mọi ô cần thiết đã được kiểm tra, mà không tiết lộ nội dung bên trong. Sau đó, nullifier giúp mạng từ chối một lần chi tiêu thứ hai mà không phải xác định note nào trong cây công khai đã được dùng. Tôi đã đọc lại đoạn đó hai lần—rồi một thông báo kéo tôi ra khỏi nó—bởi vì “riêng tư” không có nghĩa là “không có gì được kiểm tra”. Nó có nghĩa là mạng kiểm tra một bằng chứng thay vì các chi tiết giao dịch bị che giấu. Các viewing key có thể được dùng để tiết lộ thông tin một cách chọn lọc.

Việc đạt đồng thuận cũng cần thêm một lượt xem. Dusk gọi đó là Succinct Attestation (Xác thực gọn nhẹ): các staker, hay provisioners, khóa DUSK; việc chọn proposer theo tỷ trọng stake và xác định trước sẽ xác định người đề xuất một block, sau đó một ủy ban sẽ xác thực và một ủy ban khác phê chuẩn. Các chữ ký gộp lại trở thành một bản attestation rằng một quorum đã đồng ý. Vì vậy $DUSK vừa là gas vừa là phần stake đứng sau sự tham gia.

Phần tôi sẽ xem tiếp theo là mức độ tập trung. Việc chọn người là không cần xin phép, nhưng trong thực tế, mức độ phân tán của các “committee credits” hiệu quả ra sao? Trong những trang tôi đọc, tôi không tìm thấy một bản tường thuật rõ ràng về việc ai thay đổi các tham số toàn cục—có thể tôi đã bỏ sót.

Những bằng chứng nào sẽ cho thấy quyền lực của ủy ban thực sự được phân tán? Các viewing keys được quản trị thế nào trong các triển khai thực tế? Ai có thể thay đổi tham số giao thức, và theo quy trình nào?
#dusk $DUSK @Dusk
#termmax @termmax Tôi đã xem lại tài liệu TermMax vào tối qua. Cách hiểu ban đầu của tôi là nó chỉ khóa một lãi suất cho vay và phát hành một biên lai. Tài liệu cho biết FT là một ERC-20 được mua với giá thấp hơn mệnh giá và có thể đổi lấy một token nợ vào thời điểm đáo hạn. XT là ERC-20 biểu thị nghĩa vụ lãi suất; giá trị hiện tại của FT và XT bằng với số tiền vay ban đầu. GT là một ERC-721 ghi nhận tài sản thế chấp và nợ cho một vị thế vay. Một lệnh theo dải (range order) nhóm các lệnh liên tiếp được cấu hình bởi người thiết lập lệnh (order setter) hoặc người quản tuyển (curator). Đường cong giá của nó có các đoạn với giới hạn APR trên và giới hạn XT dưới. Khi các giao dịch thay đổi dự trữ XT, mức lãi suất khớp lệnh sẽ di chuyển dọc theo đường cong. Điều đó khiến tôi nhìn nhận nó theo cách khác. Bản whitepaper dùng tỉ lệ thời gian là số ngày đến đáo hạn chia cho 365; các hợp đồng dùng số ngày còn lại trong các phép tính theo đường cong. FT cũng có thể được bán trước khi đáo hạn. Theo cách tôi hiểu, việc thoát sớm phụ thuộc vào giá và thanh khoản sẵn có, chứ không chỉ dựa vào việc đáo hạn. Cách hiểu của tôi là việc thiết lập lãi suất được thể hiện thông qua việc phân bổ thanh khoản. Khi thanh khoản FT mỏng đi hoặc phần lớn thanh khoản nằm trong một đoạn duy nhất thì việc thực thi hoạt động như thế nào? Trong giai đoạn thị trường biến động mạnh, cơ chế chuyển đổi dự phòng của oracle, thanh khoản DEX, năng lực thanh lý và các tham số của giao thức tương tác với nhau ra sao? Curator và các vai trò quản trị còn giữ được mức kiểm soát nào? Tôi muốn quan sát điều này trong thực tế.
#termmax @TermMax

Tôi đã xem lại tài liệu TermMax vào tối qua. Cách hiểu ban đầu của tôi là nó chỉ khóa một lãi suất cho vay và phát hành một biên lai. Tài liệu cho biết FT là một ERC-20 được mua với giá thấp hơn mệnh giá và có thể đổi lấy một token nợ vào thời điểm đáo hạn. XT là ERC-20 biểu thị nghĩa vụ lãi suất; giá trị hiện tại của FT và XT bằng với số tiền vay ban đầu. GT là một ERC-721 ghi nhận tài sản thế chấp và nợ cho một vị thế vay.

Một lệnh theo dải (range order) nhóm các lệnh liên tiếp được cấu hình bởi người thiết lập lệnh (order setter) hoặc người quản tuyển (curator). Đường cong giá của nó có các đoạn với giới hạn APR trên và giới hạn XT dưới. Khi các giao dịch thay đổi dự trữ XT, mức lãi suất khớp lệnh sẽ di chuyển dọc theo đường cong.

Điều đó khiến tôi nhìn nhận nó theo cách khác.

Bản whitepaper dùng tỉ lệ thời gian là số ngày đến đáo hạn chia cho 365; các hợp đồng dùng số ngày còn lại trong các phép tính theo đường cong. FT cũng có thể được bán trước khi đáo hạn. Theo cách tôi hiểu, việc thoát sớm phụ thuộc vào giá và thanh khoản sẵn có, chứ không chỉ dựa vào việc đáo hạn.

Cách hiểu của tôi là việc thiết lập lãi suất được thể hiện thông qua việc phân bổ thanh khoản. Khi thanh khoản FT mỏng đi hoặc phần lớn thanh khoản nằm trong một đoạn duy nhất thì việc thực thi hoạt động như thế nào? Trong giai đoạn thị trường biến động mạnh, cơ chế chuyển đổi dự phòng của oracle, thanh khoản DEX, năng lực thanh lý và các tham số của giao thức tương tác với nhau ra sao? Curator và các vai trò quản trị còn giữ được mức kiểm soát nào?

Tôi muốn quan sát điều này trong thực tế.
#dusk $DUSK @Dusk_Foundation Tối qua tôi đã xem lại tài liệu của Dusk vì “DeFi được quản lý” thì nói thì dễ, nhưng để hình dung nó như một hệ thống thì lại khó. Ban đầu tôi nghĩ ý tưởng chính là token hóa riêng tư. Vài trang sau, quan điểm của tôi thay đổi: token chỉ là một mảnh ghép. Phần khó hơn là ghép nối danh tính, các quy tắc chuyển nhượng và cơ chế thanh toán mà không làm lộ mọi số dư hay thông tin/giấy tờ xác thực. Sự tách đôi giữa DuskVM/DuskEVM đã giúp ích. DuskVM chạy các hợp đồng Rust/WASM trên L1; còn DuskEVM cho phép các ứng dụng Solidity công bố dữ liệu và thực hiện thanh toán qua DuskDS. Theo cách tôi hiểu, một hướng đi đi sát hơn với các công cụ quyền riêng tư “nội sinh” của Dusk, trong khi hướng còn lại hạ thấp rào cản cho các nhà phát triển Ethereum. Citadel là nơi tôi vẫn còn nhiều câu hỏi. Việc chứng minh “tôi đủ điều kiện” mà không tiết lộ một hồ sơ danh tính đầy đủ là hợp lý, nhưng ai là người cấp và ai thu hồi các chứng chỉ? Điều gì xảy ra nếu bên cấp bị xâm phạm? Ai kiểm soát quyền truy cập khi việc tiết lộ được yêu cầu theo pháp luật? Tôi cũng chưa chắc cơ chế phi tập trung vận hành như thế nào trên toàn bộ ngăn xếp. Succinct Attestation được mô tả là permissionless và dựa trên ủy ban, nhưng mức độ phi tập trung của bộ sắp xếp (sequencer) trong DuskEVM là thế nào? Ai có thể nâng cấp cầu nối (bridges) hoặc các hợp đồng lõi, và những kiểm tra nào được áp dụng? Quy trình DIP ghi lại các đề xuất, nhưng tôi không tìm thấy câu trả lời rõ ràng về các quyết định cuối cùng. Giả định bảo mật lớn nhất nằm ở đâu? Liệu quyền riêng tư, sự kiểm soát theo quy định và tính trung lập đáng tin có thể cùng tồn tại mà không cái nào áp đảo các cái còn lại?
#dusk $DUSK @Dusk
Tối qua tôi đã xem lại tài liệu của Dusk vì “DeFi được quản lý” thì nói thì dễ, nhưng để hình dung nó như một hệ thống thì lại khó.

Ban đầu tôi nghĩ ý tưởng chính là token hóa riêng tư. Vài trang sau, quan điểm của tôi thay đổi: token chỉ là một mảnh ghép. Phần khó hơn là ghép nối danh tính, các quy tắc chuyển nhượng và cơ chế thanh toán mà không làm lộ mọi số dư hay thông tin/giấy tờ xác thực.

Sự tách đôi giữa DuskVM/DuskEVM đã giúp ích. DuskVM chạy các hợp đồng Rust/WASM trên L1; còn DuskEVM cho phép các ứng dụng Solidity công bố dữ liệu và thực hiện thanh toán qua DuskDS. Theo cách tôi hiểu, một hướng đi đi sát hơn với các công cụ quyền riêng tư “nội sinh” của Dusk, trong khi hướng còn lại hạ thấp rào cản cho các nhà phát triển Ethereum.

Citadel là nơi tôi vẫn còn nhiều câu hỏi. Việc chứng minh “tôi đủ điều kiện” mà không tiết lộ một hồ sơ danh tính đầy đủ là hợp lý, nhưng ai là người cấp và ai thu hồi các chứng chỉ? Điều gì xảy ra nếu bên cấp bị xâm phạm? Ai kiểm soát quyền truy cập khi việc tiết lộ được yêu cầu theo pháp luật?

Tôi cũng chưa chắc cơ chế phi tập trung vận hành như thế nào trên toàn bộ ngăn xếp. Succinct Attestation được mô tả là permissionless và dựa trên ủy ban, nhưng mức độ phi tập trung của bộ sắp xếp (sequencer) trong DuskEVM là thế nào? Ai có thể nâng cấp cầu nối (bridges) hoặc các hợp đồng lõi, và những kiểm tra nào được áp dụng? Quy trình DIP ghi lại các đề xuất, nhưng tôi không tìm thấy câu trả lời rõ ràng về các quyết định cuối cùng.

Giả định bảo mật lớn nhất nằm ở đâu? Liệu quyền riêng tư, sự kiểm soát theo quy định và tính trung lập đáng tin có thể cùng tồn tại mà không cái nào áp đảo các cái còn lại?
NHANH: 🇺🇸 Melania Trump hiện đã đạt mức đánh giá phê duyệt thấp nhất đối với một Đệ nhất phu nhân trong lịch sử nước Mỹ, chạm mốc -12. Trong suốt cả năm, bà chỉ có 38 lần xuất hiện công khai và đã không được nhìn thấy trước công chúng kể từ khi tham dự trận chung kết FIFA World Cup vào ngày 19 tháng 7. #SECCancelsCryptoRulemakingMeeting #SP500TopsRecord7800
NHANH: 🇺🇸 Melania Trump hiện đã đạt mức đánh giá phê duyệt thấp nhất đối với một Đệ nhất phu nhân trong lịch sử nước Mỹ, chạm mốc -12.

Trong suốt cả năm, bà chỉ có 38 lần xuất hiện công khai và đã không được nhìn thấy trước công chúng kể từ khi tham dự trận chung kết FIFA World Cup vào ngày 19 tháng 7.

#SECCancelsCryptoRulemakingMeeting
#SP500TopsRecord7800
Binance đã lên lịch bảo trì ví BNB Smart Chain (BEP20) vào ngày 20 tháng 8 năm 2026 lúc 06:00 (UTC). Việc nạp và rút qua mạng sẽ bị tạm dừng từ 05:55 (UTC), và thời gian bảo trì dự kiến kéo dài khoảng một giờ. Việc giao dịch các token được hỗ trợ trên BNB Smart Chain sẽ không bị ảnh hưởng, vì vậy gián đoạn chỉ áp dụng cho nạp và rút. Binance cho biết các dịch vụ này sẽ mở lại ngay khi mạng được đánh giá là ổn định, mà không có thông báo cập nhật riêng. Bất kỳ ai dự định chuyển tài sản BEP20 qua Binance có thể muốn hoàn tất giao dịch trước khi thời gian tạm dừng bắt đầu để tránh khả năng bị chậm trễ. {spot}(BNBUSDT)
Binance đã lên lịch bảo trì ví BNB Smart Chain (BEP20) vào ngày 20 tháng 8 năm 2026 lúc 06:00 (UTC). Việc nạp và rút qua mạng sẽ bị tạm dừng từ 05:55 (UTC), và thời gian bảo trì dự kiến kéo dài khoảng một giờ.

Việc giao dịch các token được hỗ trợ trên BNB Smart Chain sẽ không bị ảnh hưởng, vì vậy gián đoạn chỉ áp dụng cho nạp và rút. Binance cho biết các dịch vụ này sẽ mở lại ngay khi mạng được đánh giá là ổn định, mà không có thông báo cập nhật riêng.

Bất kỳ ai dự định chuyển tài sản BEP20 qua Binance có thể muốn hoàn tất giao dịch trước khi thời gian tạm dừng bắt đầu để tránh khả năng bị chậm trễ.
🇺🇸 TÒA BẠCH ỐC ĐANG TỔ CHỨC CUỘC HỌP CRYPTO QUAN TRỌNG NHẤT TRONG LỊCH SỬ ĐẾN THỜI ĐIỂM NÀY NGAY TRONG TUẦN NÀY! Dưới sự hiện diện của Tổng thống Trump, Chủ tịch SEC Atkins, Chủ tịch CFTC Selig và các công ty crypto như Coinbase, Ripple, Gemini, Polymarket, Kalshi, Nasdaq, NYSE, CME và DTCC, cùng nhiều đơn vị khác. Tuy nhiên, chi tiết đáng chú ý nhất nằm ở họ tên cuối cùng trong danh sách đó! DTCC là tổ chức thực hiện việc thanh toán phần lớn các giao dịch cổ phiếu tại Mỹ. Vậy tại sao lại tham khảo họ về dự luật nếu họ đã đang hoàn tất việc thanh toán? Kết luận hợp lý duy nhất là Tổng thống Trump đã cho phép bắt đầu triển khai. Diễn biến này đủ quan trọng đến mức không cần Đạo luật CLARITY phải có hiệu lực. {spot}(BTCUSDT) {spot}(BNBUSDT) #IsraelStrikesLebanonKillsHezbollahCommander #SP500TopsRecord7800 #SP500EarningsBeatExpectations #USToPressNationsToPickUSOrChinaAICoalition
🇺🇸 TÒA BẠCH ỐC ĐANG TỔ CHỨC CUỘC HỌP CRYPTO QUAN TRỌNG NHẤT TRONG LỊCH SỬ ĐẾN THỜI ĐIỂM NÀY NGAY TRONG TUẦN NÀY!

Dưới sự hiện diện của Tổng thống Trump, Chủ tịch SEC Atkins, Chủ tịch CFTC Selig và các công ty crypto như Coinbase, Ripple, Gemini, Polymarket, Kalshi, Nasdaq, NYSE, CME và DTCC, cùng nhiều đơn vị khác. Tuy nhiên, chi tiết đáng chú ý nhất nằm ở họ tên cuối cùng trong danh sách đó!

DTCC là tổ chức thực hiện việc thanh toán phần lớn các giao dịch cổ phiếu tại Mỹ. Vậy tại sao lại tham khảo họ về dự luật nếu họ đã đang hoàn tất việc thanh toán? Kết luận hợp lý duy nhất là Tổng thống Trump đã cho phép bắt đầu triển khai. Diễn biến này đủ quan trọng đến mức không cần Đạo luật CLARITY phải có hiệu lực.


#IsraelStrikesLebanonKillsHezbollahCommander
#SP500TopsRecord7800
#SP500EarningsBeatExpectations
#USToPressNationsToPickUSOrChinaAICoalition
#dusk $DUSK @Dusk_Foundation Tôi đã đủ lâu trong lĩnh vực này để nhận ra rằng crypto thường coi quyền riêng tư như một tính năng “chuyển giao”: ẩn người gửi, người nhận hoặc số tiền, rồi coi như xong việc. Điều đó quan trọng, nhưng một khoản thanh toán riêng lẻ vẫn chưa tạo nên một hệ thống tài chính riêng tư. Ứng dụng đứng sau nó vẫn có thể lộ vị trí, tính đủ điều kiện, đối tác và các quy tắc giao dịch. Có điều gì đó về Dusk đã thu hút sự chú ý của tôi. Phoenix cung cấp các giao dịch được che chắn dựa trên “note”, trong khi Moonlight lại duy trì một đường đi công khai cho tài khoản. Thú vị hơn là những gì nằm phía trên phần thanh toán. Lớp hợp đồng và nhận dạng của Dusk được thiết kế để một ứng dụng có thể kiểm tra tính đủ điều kiện, thực thi các điều kiện chuyển tiền hoặc thanh toán bù trừ, đồng thời tiết lộ các dữ kiện được chọn cho một tổ chức phát hành hoặc kiểm toán viên mà không phải công bố tất cả. Tôi đã từng thấy những ý tưởng tương tự trước đây, và phần khó hiếm khi chỉ là mật mã. Vấn đề là phải quyết định ranh giới của quyền riêng tư: ai được quyền xem, quyền truy cập được quản trị như thế nào, những dữ liệu siêu (metadata) nào bị rò rỉ, và liệu người dùng có hiểu được các lựa chọn hay không. Tài chính riêng tư vẫn cần thanh khoản, định giá, khả năng khôi phục và các ví tử tế. Việc thực thi có bảo mật không xóa đi những vấn đề đó. Tôi vẫn tự hỏi liệu crypto đã giới hạn quá hẹp khái niệm về quyền riêng tư. Bitcoin cho thấy giá trị có thể di chuyển mà không cần ngân hàng, nhưng sổ cái công khai của nó cũng cho thấy một dấu vết thanh toán có thể tiết lộ đến mức nào. Dusk đang thử nghiệm một ý tưởng rộng hơn: có lẽ “đơn vị hữu ích” của quyền riêng tư không phải là một giao dịch đơn lẻ, mà là mối quan hệ tài chính xung quanh nó. Tôi vẫn chưa thật sự tin rằng các đánh đổi đã được giải quyết, nhưng câu hỏi đó đáng để tiếp tục theo dõi. {spot}(DUSKUSDT)
#dusk $DUSK @Dusk

Tôi đã đủ lâu trong lĩnh vực này để nhận ra rằng crypto thường coi quyền riêng tư như một tính năng “chuyển giao”: ẩn người gửi, người nhận hoặc số tiền, rồi coi như xong việc. Điều đó quan trọng, nhưng một khoản thanh toán riêng lẻ vẫn chưa tạo nên một hệ thống tài chính riêng tư. Ứng dụng đứng sau nó vẫn có thể lộ vị trí, tính đủ điều kiện, đối tác và các quy tắc giao dịch.

Có điều gì đó về Dusk đã thu hút sự chú ý của tôi. Phoenix cung cấp các giao dịch được che chắn dựa trên “note”, trong khi Moonlight lại duy trì một đường đi công khai cho tài khoản. Thú vị hơn là những gì nằm phía trên phần thanh toán. Lớp hợp đồng và nhận dạng của Dusk được thiết kế để một ứng dụng có thể kiểm tra tính đủ điều kiện, thực thi các điều kiện chuyển tiền hoặc thanh toán bù trừ, đồng thời tiết lộ các dữ kiện được chọn cho một tổ chức phát hành hoặc kiểm toán viên mà không phải công bố tất cả.

Tôi đã từng thấy những ý tưởng tương tự trước đây, và phần khó hiếm khi chỉ là mật mã. Vấn đề là phải quyết định ranh giới của quyền riêng tư: ai được quyền xem, quyền truy cập được quản trị như thế nào, những dữ liệu siêu (metadata) nào bị rò rỉ, và liệu người dùng có hiểu được các lựa chọn hay không. Tài chính riêng tư vẫn cần thanh khoản, định giá, khả năng khôi phục và các ví tử tế. Việc thực thi có bảo mật không xóa đi những vấn đề đó.

Tôi vẫn tự hỏi liệu crypto đã giới hạn quá hẹp khái niệm về quyền riêng tư. Bitcoin cho thấy giá trị có thể di chuyển mà không cần ngân hàng, nhưng sổ cái công khai của nó cũng cho thấy một dấu vết thanh toán có thể tiết lộ đến mức nào. Dusk đang thử nghiệm một ý tưởng rộng hơn: có lẽ “đơn vị hữu ích” của quyền riêng tư không phải là một giao dịch đơn lẻ, mà là mối quan hệ tài chính xung quanh nó. Tôi vẫn chưa thật sự tin rằng các đánh đổi đã được giải quyết, nhưng câu hỏi đó đáng để tiếp tục theo dõi.
Đã xác minh
#dusk $DUSK Dilemma blockchain mang tính xác định trong thế giới Blockchain là gì? Các blockchain công khai phơi bày mọi thứ—mọi giao dịch, ví và khoản thanh toán. Hãy tưởng tượng một ngân hàng đăng danh mục khách hàng và các lệnh giao dịch lên một tấm billboard. Các tổ chức phát triển nhờ sự kín kẽ, vì vậy họ từ chối. Các chuỗi hoàn toàn riêng tư lại tạo ra điều ngược lại. Danh tính tan biến như khói. Ẩn danh tuyệt đối. Không có kiểm toán. Không có sự giám sát. Cơ quan quản lý bước vào rồi rút lui. Đó không phải là quyền riêng tư. Đó là sự lẩn tránh được khoác lên lớp mã hóa. Dusk Network bác bỏ lựa chọn giả tạo này. Nó cung cấp tiết lộ chọn lọc—một lưỡi mổ trong thế giới toàn búa tạ. Zero-knowledge proofs (bằng chứng không tri thức) tạo ra con đường giữa việc phơi bày và che giấu. Chứng minh sự tuân thủ mà không để lộ bài toán của bạn. Xuất “biên lai” cho cơ quan quản lý trong khi vẫn giữ kín số dư, đối tác và tài sản nắm giữ. Cần có xác minh. Đây là chìa khóa. Mọi người khác chỉ thấy bóng tối. Moonlight hiện thực hóa kiến trúc song song giữa minh bạch và bí mật. Chế độ công khai của nó tỏa sáng khi sự cởi mở là điều quan trọng. Phoenix—người anh em được mã hóa của nó—che giấu các khoản tiền, người gửi và người nhận trong khi vẫn bảo toàn tính hợp lệ của bằng chứng. Lật một công tắc và đổi thế giới. Không phải một sự thỏa hiệp. Một dải quyền chủ quyền. Citadel dệt danh tính lên chuỗi, cho phép KYC và AML mà không hy sinh quyền riêng tư. Chuẩn XSC nhúng sự tuân thủ vào chứng khoán kỹ thuật số ngay từ khi được sinh ra, bao gồm trái phiếu, quỹ và cổ phiếu. Mọi thứ đều nhận thức được quy tắc. Quyền riêng tư không phải là nổi loạn. Đó là nền tảng của trách nhiệm giải trình. Đây không phải lý thuyết từ một bản PDF. Vào ngày 7 tháng 1 năm 2026, Dusk mainnet sẽ được thắp sáng. DuskEVM khởi động. Các nhà phát triển Solidity, công cụ của bạn đã sẵn sàng. Với NPEX, một sàn giao dịch được cấp phép tại Hà Lan, Dusk sẽ đưa hàng trăm triệu chứng khoán được token hóa lên chuỗi. Tài sản thật. Tầm vóc thật. Với Quantoz Payments, họ tạo ra EURQ—đồng euro kỹ thuật số tuân thủ MiCA. Neo chặt và hiện thực. Quá phơi bày. Quá tăm tối. Dusk nói: hãy chọn ánh sáng, chọn bóng râm. Che giấu những gì phải được giữ kín. Tiết lộ những gì cần được nhìn thấy. Đây không phải là cân bằng. Đó là sự kiểm soát. @Dusk_Foundation
#dusk $DUSK Dilemma blockchain mang tính xác định trong thế giới Blockchain là gì?

Các blockchain công khai phơi bày mọi thứ—mọi giao dịch, ví và khoản thanh toán. Hãy tưởng tượng một ngân hàng đăng danh mục khách hàng và các lệnh giao dịch lên một tấm billboard. Các tổ chức phát triển nhờ sự kín kẽ, vì vậy họ từ chối.

Các chuỗi hoàn toàn riêng tư lại tạo ra điều ngược lại. Danh tính tan biến như khói. Ẩn danh tuyệt đối. Không có kiểm toán. Không có sự giám sát. Cơ quan quản lý bước vào rồi rút lui. Đó không phải là quyền riêng tư. Đó là sự lẩn tránh được khoác lên lớp mã hóa.

Dusk Network bác bỏ lựa chọn giả tạo này.

Nó cung cấp tiết lộ chọn lọc—một lưỡi mổ trong thế giới toàn búa tạ. Zero-knowledge proofs (bằng chứng không tri thức) tạo ra con đường giữa việc phơi bày và che giấu. Chứng minh sự tuân thủ mà không để lộ bài toán của bạn. Xuất “biên lai” cho cơ quan quản lý trong khi vẫn giữ kín số dư, đối tác và tài sản nắm giữ. Cần có xác minh. Đây là chìa khóa. Mọi người khác chỉ thấy bóng tối.

Moonlight hiện thực hóa kiến trúc song song giữa minh bạch và bí mật. Chế độ công khai của nó tỏa sáng khi sự cởi mở là điều quan trọng. Phoenix—người anh em được mã hóa của nó—che giấu các khoản tiền, người gửi và người nhận trong khi vẫn bảo toàn tính hợp lệ của bằng chứng. Lật một công tắc và đổi thế giới. Không phải một sự thỏa hiệp. Một dải quyền chủ quyền.

Citadel dệt danh tính lên chuỗi, cho phép KYC và AML mà không hy sinh quyền riêng tư. Chuẩn XSC nhúng sự tuân thủ vào chứng khoán kỹ thuật số ngay từ khi được sinh ra, bao gồm trái phiếu, quỹ và cổ phiếu. Mọi thứ đều nhận thức được quy tắc. Quyền riêng tư không phải là nổi loạn. Đó là nền tảng của trách nhiệm giải trình.

Đây không phải lý thuyết từ một bản PDF.

Vào ngày 7 tháng 1 năm 2026, Dusk mainnet sẽ được thắp sáng. DuskEVM khởi động. Các nhà phát triển Solidity, công cụ của bạn đã sẵn sàng.

Với NPEX, một sàn giao dịch được cấp phép tại Hà Lan, Dusk sẽ đưa hàng trăm triệu chứng khoán được token hóa lên chuỗi. Tài sản thật. Tầm vóc thật.

Với Quantoz Payments, họ tạo ra EURQ—đồng euro kỹ thuật số tuân thủ MiCA. Neo chặt và hiện thực.

Quá phơi bày. Quá tăm tối.

Dusk nói: hãy chọn ánh sáng, chọn bóng râm. Che giấu những gì phải được giữ kín. Tiết lộ những gì cần được nhìn thấy. Đây không phải là cân bằng. Đó là sự kiểm soát.
@Dusk
#dusk $DUSK Tôi nhận thấy rằng càng dành nhiều thời gian để sử dụng các blockchain minh bạch, ý niệm “minh bạch” càng trở nên phức tạp. Lần đầu tiên tôi chờ một giao dịch Ethereum được xác nhận, sự tò mò đã đưa tôi đến một trình khám phá khối (block explorer). Điều khiến tôi ngạc nhiên không phải là độ trễ, mà là việc một địa chỉ công khai có thể lộ ra nhiều lịch sử tài chính đến mức nào. Sự minh bạch đó hữu ích cho việc xác minh, nhưng lại trở nên khó chịu khi mô hình tương tự được áp dụng cho các tổ chức có thể không muốn hoặc không thể công khai mọi vị thế, số dư hay mối quan hệ đối tác. Đó là lý do @Dusk_Foundation khiến tôi thấy hứng thú. Dusk không chỉ đơn giản là làm mọi thứ trở nên riêng tư. Kiến trúc của nó cung cấp các mô hình hiển thị khác nhau. Moonlight là minh bạch và theo mô hình tài khoản, trong khi Phoenix cung cấp các chuyển tiền UTXO được che chắn. Trong các giao dịch Phoenix, người gửi, người nhận và số tiền được chuyển được ẩn khỏi công chúng, trong khi các bên liên quan và những người nắm giữ khóa xem (view key) phù hợp có thể truy cập các thông tin liên quan. Vì vậy, ý quan trọng không phải là “riêng tư đối đầu với minh bạch”. Đó là khả năng hiển thị có thể lập trình (programmable visibility). Dusk cũng sử dụng các bằng chứng không kiến thức (zero-knowledge proofs) và công bố chọn lọc, cho phép các quy trình tài chính giữ kín những thông tin không cần thiết, đồng thời cung cấp bằng chứng có kiểm soát khi các bên được ủy quyền cần đến. Đồng thuận Succinct Attestation của nó cung cấp tính xác nhận cuối cùng (finality) mang tính tất định ngay khi một khối được phê chuẩn. Ethereum cũng không đứng yên. Các công nghệ riêng tư tiếp tục phát triển tại đó, trong khi các ZK-rollups không nên tự động được xem như là các hệ thống giao dịch riêng tư, vì vai trò chính của chúng là mở rộng thông qua các bằng chứng tính đúng đắn (validity proofs). Vì thế, tôi liên tục quay lại một câu hỏi: nếu hoạt động tài chính có thể được che chắn mặc định, thì kiểm toán viên được phép tiếp cận những gì, và ai là người kiểm soát quyền đó? Ranh giới này có thể quan trọng đối với việc các tổ chức áp dụng công nghệ hơn là chỉ đơn thuần làm cho mọi giao dịch đều công khai.
#dusk $DUSK
Tôi nhận thấy rằng càng dành nhiều thời gian để sử dụng các blockchain minh bạch, ý niệm “minh bạch” càng trở nên phức tạp.

Lần đầu tiên tôi chờ một giao dịch Ethereum được xác nhận, sự tò mò đã đưa tôi đến một trình khám phá khối (block explorer). Điều khiến tôi ngạc nhiên không phải là độ trễ, mà là việc một địa chỉ công khai có thể lộ ra nhiều lịch sử tài chính đến mức nào. Sự minh bạch đó hữu ích cho việc xác minh, nhưng lại trở nên khó chịu khi mô hình tương tự được áp dụng cho các tổ chức có thể không muốn hoặc không thể công khai mọi vị thế, số dư hay mối quan hệ đối tác.

Đó là lý do @Dusk khiến tôi thấy hứng thú.

Dusk không chỉ đơn giản là làm mọi thứ trở nên riêng tư. Kiến trúc của nó cung cấp các mô hình hiển thị khác nhau. Moonlight là minh bạch và theo mô hình tài khoản, trong khi Phoenix cung cấp các chuyển tiền UTXO được che chắn. Trong các giao dịch Phoenix, người gửi, người nhận và số tiền được chuyển được ẩn khỏi công chúng, trong khi các bên liên quan và những người nắm giữ khóa xem (view key) phù hợp có thể truy cập các thông tin liên quan.

Vì vậy, ý quan trọng không phải là “riêng tư đối đầu với minh bạch”. Đó là khả năng hiển thị có thể lập trình (programmable visibility).

Dusk cũng sử dụng các bằng chứng không kiến thức (zero-knowledge proofs) và công bố chọn lọc, cho phép các quy trình tài chính giữ kín những thông tin không cần thiết, đồng thời cung cấp bằng chứng có kiểm soát khi các bên được ủy quyền cần đến. Đồng thuận Succinct Attestation của nó cung cấp tính xác nhận cuối cùng (finality) mang tính tất định ngay khi một khối được phê chuẩn.

Ethereum cũng không đứng yên. Các công nghệ riêng tư tiếp tục phát triển tại đó, trong khi các ZK-rollups không nên tự động được xem như là các hệ thống giao dịch riêng tư, vì vai trò chính của chúng là mở rộng thông qua các bằng chứng tính đúng đắn (validity proofs).

Vì thế, tôi liên tục quay lại một câu hỏi: nếu hoạt động tài chính có thể được che chắn mặc định, thì kiểm toán viên được phép tiếp cận những gì, và ai là người kiểm soát quyền đó?

Ranh giới này có thể quan trọng đối với việc các tổ chức áp dụng công nghệ hơn là chỉ đơn thuần làm cho mọi giao dịch đều công khai.
Đã xác minh
#dusk $DUSK Tôi nhận thấy phần khó nhất khi đưa tài sản thế giới thực lên onchain không phải là token hóa. Mà là điều gì xảy ra sau khi tài sản đã được đưa đến. Các thị trường được quản lý yêu cầu kiểm tra danh tính, hạn chế chuyển nhượng, khả năng kiểm toán và tính riêng tư thương mại. DeFi phụ thuộc vào hạ tầng mở và khả năng tương tác. Việc làm cho các hệ thống đó cùng tồn tại mà không làm suy yếu các yêu cầu cốt lõi của chúng chính là thách thức thực sự—và cũng là lý do @Dusk_Foundation và Dusk Trade đáng để xem xét. Dusk Trade đang được xây dựng như một lớp ứng dụng cho các tài sản tài chính được token hóa, với các quy trình bao gồm giới thiệu nhà đầu tư, liên kết ví, chuyển nhượng được kiểm soát, điều phối thanh toán và quyết toán tuân thủ. Bên dưới, mạng Dusk trực tiếp kết hợp tính tất định với các mô hình giao dịch hướng đến quyền riêng tư và khả năng tiết lộ có chọn lọc. DuskEVM, hiện đang chạy trên testnet, cung cấp một môi trường tương thích Solidity được kết nối với hạ tầng quyết toán của Dusk. Hedger, cũng đang trên testnet, được thiết kế để đưa các quy trình EVM bí mật thông qua mã hóa đồng cấu và các bằng chứng không kiến thức. Mục tiêu là giữ cho số dư nhạy cảm và chi tiết giao dịch được riêng tư, đồng thời vẫn đảm bảo việc thực thi có thể được xác minh và đánh giá bởi bên được ủy quyền. Quan hệ đối tác NPEX kết nối luận điểm này với hạ tầng châu Âu được quản lý. Tuy nhiên, một quan hệ đối tác được quản lý không phải là sự phê duyệt cho toàn bộ mô hình onchain, và công nghệ testnet không phải là quyết toán trong môi trường sản xuất. Câu hỏi trọng tâm là liệu các cơ chế kiểm soát ở mức MTF có thể cùng tồn tại với thanh khoản DeFi thực sự có ý nghĩa hay không. Những cơ chế kiểm soát đó có thể khiến chứng khoán được token hóa trở nên phù hợp với các tổ chức, nhưng cũng có thể hạn chế khả năng di chuyển của chúng giữa các thị trường cho vay và các nhóm thanh khoản. DUSK đã trả cho chi phí thực thi, hỗ trợ staking và giúp bảo đảm an toàn cho hệ sinh thái. Điều chưa được chứng minh là liệu hoạt động tài chính trực tiếp có tạo ra nhu cầu bền vững ở quy mô lớn hay không. Tôi sẽ theo dõi tiến trình quản lý, việc phát hành trực tiếp, khối lượng quyết toán và việc sử dụng thường xuyên của các tổ chức—không phải các mục tiêu mang tính quảng bá. Liệu các cơ chế kiểm soát được quản lý và khả năng tương tác của DeFi có thể thật sự cùng tồn tại ở quy mô lớn?
#dusk $DUSK
Tôi nhận thấy phần khó nhất khi đưa tài sản thế giới thực lên onchain không phải là token hóa. Mà là điều gì xảy ra sau khi tài sản đã được đưa đến.

Các thị trường được quản lý yêu cầu kiểm tra danh tính, hạn chế chuyển nhượng, khả năng kiểm toán và tính riêng tư thương mại. DeFi phụ thuộc vào hạ tầng mở và khả năng tương tác. Việc làm cho các hệ thống đó cùng tồn tại mà không làm suy yếu các yêu cầu cốt lõi của chúng chính là thách thức thực sự—và cũng là lý do @Dusk và Dusk Trade đáng để xem xét.

Dusk Trade đang được xây dựng như một lớp ứng dụng cho các tài sản tài chính được token hóa, với các quy trình bao gồm giới thiệu nhà đầu tư, liên kết ví, chuyển nhượng được kiểm soát, điều phối thanh toán và quyết toán tuân thủ.

Bên dưới, mạng Dusk trực tiếp kết hợp tính tất định với các mô hình giao dịch hướng đến quyền riêng tư và khả năng tiết lộ có chọn lọc. DuskEVM, hiện đang chạy trên testnet, cung cấp một môi trường tương thích Solidity được kết nối với hạ tầng quyết toán của Dusk.

Hedger, cũng đang trên testnet, được thiết kế để đưa các quy trình EVM bí mật thông qua mã hóa đồng cấu và các bằng chứng không kiến thức. Mục tiêu là giữ cho số dư nhạy cảm và chi tiết giao dịch được riêng tư, đồng thời vẫn đảm bảo việc thực thi có thể được xác minh và đánh giá bởi bên được ủy quyền.

Quan hệ đối tác NPEX kết nối luận điểm này với hạ tầng châu Âu được quản lý. Tuy nhiên, một quan hệ đối tác được quản lý không phải là sự phê duyệt cho toàn bộ mô hình onchain, và công nghệ testnet không phải là quyết toán trong môi trường sản xuất.

Câu hỏi trọng tâm là liệu các cơ chế kiểm soát ở mức MTF có thể cùng tồn tại với thanh khoản DeFi thực sự có ý nghĩa hay không. Những cơ chế kiểm soát đó có thể khiến chứng khoán được token hóa trở nên phù hợp với các tổ chức, nhưng cũng có thể hạn chế khả năng di chuyển của chúng giữa các thị trường cho vay và các nhóm thanh khoản.

DUSK đã trả cho chi phí thực thi, hỗ trợ staking và giúp bảo đảm an toàn cho hệ sinh thái. Điều chưa được chứng minh là liệu hoạt động tài chính trực tiếp có tạo ra nhu cầu bền vững ở quy mô lớn hay không.

Tôi sẽ theo dõi tiến trình quản lý, việc phát hành trực tiếp, khối lượng quyết toán và việc sử dụng thường xuyên của các tổ chức—không phải các mục tiêu mang tính quảng bá.

Liệu các cơ chế kiểm soát được quản lý và khả năng tương tác của DeFi có thể thật sự cùng tồn tại ở quy mô lớn?
Đă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.
Email / Số điện thoại
Sơ đồ trang web
Tùy chọn Cookie
Điều khoản & Điều kiện