Rokyo

I wanted to know what "Connect Wallet" actually gives a dApp access to, so I tested the real flow on Dario and Pieswap on Dusk testnet. On both, the first connection returned only the profile ID and public account. The popup was explicit: "The site will only be able to use the selected profile's public account." Only when I requested the shielded receive address did a second consent step appear, and only then did the response include shieldedAddress. The popup changed too, naming the "shareable shielded receive address." Both integrations showed the same sequence.

Here's the flip: I was treating "Connect Wallet" as one permission event. It isn't. The controlled test separated public-account access from sharing the shielded receive address at the point of consent.

That separation puts part of the minimum-disclosure boundary in the wallet's consent flow, not entirely on the user to manage. In both tests, clicking "Connect" alone never granted the shielded-address scope; a dApp had to cross a separate consent step to get it.

I also got one thing wrong while investigating. I thought the 132-character account string might hint at shielded access. It doesn't. Both dApps returned the same account format on baseline, while shieldedAddress stayed absent until the explicit request.

There's still one unresolved question. An earlier Dario mainnet session behaved differently, but I haven't reproduced it under the same controlled conditions, so I'm not calling it a leak. I can only say the public-only permission boundary held across the two testnet integrations I checked, not that it is guaranteed across every environment.

"A wallet connection should expose the scope you approved, not leave you to infer it."

What I'd want to see next: the same controlled test on mainnet with the same wallet version, clean permissions, and identical instrumentation, to see whether the boundary holds across environments.

#dusk $DUSK @Dusk

I assumed that if I wanted to do three things on-chain, approve, swap, then stake, the chain would treat that as one thing happening or not happening at all. An open issue in Dusk's own Rusk repository says that's not how it works today.

A Dusk transaction today carries a single optional operation: one contract call, one deploy, or one memo, with one value, one recipient, one nonce, one signature. So approve, swap, and stake become three separate transactions, each independently included or dropped. Dusk's issue states it plainly: there is no atomicity guarantee across them. Land approve and swap but not stake, and you're left mid-flow with no protocol-level rollback.

The problem isn't only that multi-step flows can stop halfway. Fixing that changes who has to absorb the compatibility cost.

A batcher contract makes the whole sequence atomic, because a failed sub-call reverts the outer transaction. But a target contract checking who's calling it directly would see the batcher, not you, unless that contract is already written to look past the immediate caller. A protocol-level batch transaction keeps you as the caller at every step, but it doesn't ship without a new transaction format, consensus changes, a hard-fork, and every wallet SDK catching up.

Adding batching doesn't remove the tradeoff. It decides whether the compatibility burden sits in application authorization or in the protocol stack.

"Fixing atomicity doesn't remove the tradeoff; it decides where the compatibility burden and trust boundary move."

What I'd actually want to watch: whether Dusk chooses the application-level batcher or the protocol-level transaction, and what existing authorization assumptions that choice forces developers to change.

#dusk $DUSK @Dusk

I assumed a transaction's meaning was fixed the moment its bytes existed: decode it once, get the same answer everywhere. Dusk's own Rusk changelog for the Boreas upgrade treats that as something that has to be engineered, not assumed.

Boreas added version-aware transaction decoding tied to a specific hardfork, plus hardfork-governed format selection for how old blocks get replayed. The codebase now has two explicitly separate types, CanonicalTransaction and LedgerTransaction, splitting the in-memory representation of a transaction from the format it's actually persisted in on the ledger. There's even a dedicated regression test just for decoding pre-Aegis-era transactions correctly during block serialization.

That only becomes necessary once transaction decoding has to account for different protocol eras and processing stages: fresh off the wire from a client, sitting in memory as a canonical object, replayed from a block that predates the current rules.

Which means a protocol upgrade isn't safe just because new transactions work under the new rules. It's only safe if those new rules don't silently break the ability to correctly replay old ledger state under the rules that produced it. That is the class of version-mismatch failure the historical-replay compatibility and hardfork-gated decoding are designed to prevent.

"A transaction is only reliable if every stage that touches it agrees on what it means."

What I'd actually want to see: a real pre-Aegis block replayed on a current node without changing how its historical transactions are decoded under the applicable rules, not just a passing regression test in isolation.

#dusk $DUSK @Dusk

Tôi đã hiểu rằng “DuskEVM hỗ trợ Solidity” có nghĩa là các nhà phát triển có thể sử dụng sẵn công cụ Ethereum hiện có là xong. Tài liệu hướng dẫn nhanh của Dusk lại lặng lẽ bổ sung thêm một bước mà hầu hết mọi người bỏ qua: xác minh mã nguồn.

Triển khai thì phần dễ. DuskEVM dùng Blockscout làm trình khám phá (explorer), và khi bạn chọn “Verify & Publish” để xác minh một hợp đồng tại đó, thì các cài đặt build liên quan, phiên bản compiler, cấu hình tối ưu hóa (optimizer), các tệp nguồn, tham số constructor… đều phải tái tạo đúng bytecode mà thực tế đã được triển khai.

Đó là một tiêu chuẩn khác với tính tương thích EVM. Việc triển khai chứng minh rằng mã có thể chạy. Việc xác minh cho phép người khác kiểm tra chính xác thứ gì đang chạy. Một hợp đồng có thể được triển khai và hoạt động bình thường nhưng vẫn chưa được xác minh, khiến người khác không thể tự kiểm chứng liệu mã nguồn đã công bố có thực sự khớp với những gì đang chạy hay không.

Vì vậy, “tương thích EVM” và “sẵn sàng cho nhà phát triển” không hẳn là một tuyên bố giống nhau. Một bên nói về việc mã của bạn có chạy ở đây hay không. Bên còn lại nói về việc một bên kiểm toán, một tổ chức, hay người dùng có thực sự xác nhận được rằng những gì đang chạy khớp với những gì được khẳng định hay không.

“Một mạng (chain) có thể chạy hợp đồng Solidity của bạn và vẫn khiến bạn không thể chứng minh hợp đồng đó thực sự là gì.”

Điều tôi muốn thấy tiếp theo: liệu một hợp đồng được triển khai theo đường chuẩn của Solidity/Hardhat có thể được xác minh đáng tin cậy dựa trên bytecode đã triển khai hay không, thay vì chỉ dừng ở việc triển khai thành công.

#dusk $DUSK @Dusk

I assumed fractionalization was most of the liquidity story: split an asset into smaller pieces, and the pool of potential owners gets wider. Dusk's own writing on tokenization for SMEs, published this week, says that's a limited part of the picture, and an independent academic study of real tokenized assets shows why the gap matters.

Dusk says it plainly: "fractional ownership plays a limited role. Smaller units cannot create investor demand, legal certainty or liquidity." The value, they argue, comes from connecting the security to accountable operators, eligible buyers, reliable payment and settlement, and an authorized venue, not from how finely it's sliced.

A 2023 study published in Financial Innovation tested something close to this against real 58 tokenized residential properties in the US. On ownership, the results were clear: the average property had 254 separate owners. But on trading, the picture was different. Ownership changed hands about once a year on average, with properties on decentralized exchanges turning over more often than those traded peer-to-peer, though the yearly baseline stayed low either way.

Which means the two claims people conflate, "this asset is fractionalized" and "this asset is liquid," are actually describing two different things. Fractionalization is a property of the token. Liquidity is a property of the market around it.

"A smaller unit can widen who's allowed to own something without creating a market where they can actually trade it."

What I'd watch as NPEX-linked assets come onto Dusk: not how finely they're fractionalized at issuance, but whether secondary trading actually persists after that, the same gap the 58-property study found between wide ownership and active trading.

#dusk $DUSK @Dusk

Tôi đã nghĩ rằng một vụ hack cầu nối nghĩa là ai đó đã phát hiện ra một lỗ hổng trong mã nguồn, một điểm yếu trong mật mã, thứ mà một cuộc kiểm tra an ninh đã bỏ sót. Nhưng phần hậu kiểm (post-mortem) của Dusk về sự cố cầu nối hồi tháng Một lại mô tả một điều khác.

Vào ngày 16 tháng 1, một kẻ tấn công đã xâm nhập ví ký được dùng bởi cầu nối Dusk-to-EVM, chuyển tiền trực tiếp trên Dusk trước khi chuyển một phần trong đó đi tiếp sang BNB Smart Chain. Dusk đã tắt cầu nối giữa cuộc tấn công, và chính điều đó khiến một nỗ lực chuyển khoản cuối cùng, trị giá xấp xỉ 8,9 triệu DUSK, bị thất bại.

Đây không phải là lỗi do cơ chế đồng thuận (consensus) hay một kiểu khai thác lỗ hổng của giao thức (protocol exploit). Dusk cho biết nguyên nhân trực tiếp là việc bị lộ/đánh cắp khóa (key compromise), và thiết kế cũ cho phép ví ký, việc xử lý sự kiện (event handling) và kết nối mạng đều hoạt động trong cùng một luồng. Điểm yếu nằm ở quyền hạn vận hành tập trung, chứ không phải do mật mã yếu.

Phần thiết kế lại sau đó có thể gói gọn trong một câu được chôn trong bản hậu kiểm: "ingestion is no longer equivalent to spending" (việc nạp dữ liệu sự kiện (ingestion) không còn tương đương với việc chi tiêu/phát hành tiền). Trước đây, việc nhận ra rằng một sự kiện đã xảy ra và có thẩm quyền giải phóng tiền vì điều đó là cùng một bước. Giờ thì không còn như vậy nữa. Việc ingestion sự kiện được ghi checkpoint và đưa vào hàng đợi dưới dạng một job; một quy trình riêng biệt, rõ ràng sẽ thực sự chuyển tiền dựa trên đó.

"Một giao thức vẫn có thể hoạt động đúng như thiết kế, trong khi lớp vận hành xung quanh nó lại trao quá nhiều quyền cho một con đường bị xâm phạm."

Điều tôi thực sự muốn thấy: xác nhận rằng cây cầu nối được thiết kế lại thực sự tách bạch việc ingestion sự kiện và việc giải phóng/quyết định phát hành tiền thành hai luồng riêng trong thực tế, chứ không chỉ được mô tả trong phần hậu kiểm về kiến trúc mới.

#dusk $DUSK @Dusk

Tôi đã cho rằng một khoản vay lãi suất cố định trên TermMax chỉ có một con số: bạn vay bao nhiêu thì khoản tiền cố định đó sẽ là số tiền bạn phải trả lại sau cùng. Nhưng đó không phải là toàn bộ bức tranh.

Đây là cơ chế. Khi người vay nhận khoản vay, họ sẽ nhận token nợ và có thể hoàn trả bằng cách trả lại đúng mệnh giá đó. Tuy nhiên, TermMax cũng cho phép họ mua lại FT—token đại diện cho đúng khoản nợ đó—từ thị trường mở thay vì trả trực tiếp. FT có thể được giao dịch thấp hơn mệnh giá trước thời điểm đáo hạn, và ví dụ được TermMax trình bày minh họa cách điều này có thể làm giảm chi phí hoàn trả. Trong ví dụ đó, một người vay đang nợ 800 FT có thể mua lại với giá 0,80 USD mỗi token và thanh toán khoản nợ bằng 640 USD, thay vì trả thẳng 800 USD. Cùng một nghĩa vụ, nhưng hai mức giá khác nhau để chốt.

Điều này không phải là chênh lệch do làm tròn. Đó là khoảng chênh 20% giữa số tiền hoàn trả theo hợp đồng và chi phí thực sự để đóng vị thế, tùy thuộc vào việc FT đang được giao dịch ở mức nào trong ngày đó.

Điều này cho thấy điều gì: cùng một token FT vừa là quyền đòi lợi tức cố định của bên cho vay được nắm giữ cho đến khi đáo hạn, vừa là công cụ của người vay để tất toán nợ sớm. Khoản nợ không phải là một con số đứng yên giữa thời điểm ký kết và thời điểm đáo hạn. Nó có thể có giá thị trường trước khi đáo hạn, và giá thị trường đó có thể biến động độc lập với mức lãi suất được công bố tại thời điểm khởi tạo.

Một lưu ý đáng nêu: tài liệu riêng của TermMax dùng con số 20% này như một ví dụ minh họa, không phải là điều kiện thị trường đảm bảo. Chiết khấu thực tế của FT sẽ thay đổi theo điều kiện thị trường và không phải lúc nào cũng rộng như vậy.

Vậy con số nào nên thực sự định nghĩa một "khoản vay lãi suất cố định": mức lãi suất bạn đã khóa tại thời điểm khởi tạo, hay là giá thị trường của công cụ mà bạn cần mua để chốt khoản đó?

#termmax @TermMax

I assumed "liquidated" on TermMax meant a position was simply cleared once a liquidator stepped in. That's not quite how it works for larger positions.

Liquidation triggers when a loan's LTV breaches the LLTV threshold, or when a borrower misses the fixed maturity repayment, opening a two-hour liquidation window. But there's a cap built into the mechanism itself: if outstanding debt exceeds $10,000, a liquidator can only liquidate up to 50% of the total debt value in that pass.

So for a large enough position, the constraint isn't necessarily whether a liquidator wants to act. The protocol itself won't let any single liquidation clear the whole thing.

That changes what "partially liquidated" means. It's not necessarily evidence that liquidation demand was too thin or the market moved too fast. It can be an expected consequence of the mechanism itself. And if the loan is still unpaid or only partially liquidated when that two-hour window closes, physical delivery begins automatically.

The size of a position doesn't just affect how much is at risk. It can affect whether the liquidation process can fully resolve the position within its available window.

So should liquidation efficiency be judged by whether a liquidator shows up, or by how much of the position the mechanism can actually resolve before the window closes?

#termmax @TermMax

Câu trả lời KYC dành cho những người đã đủ điều kiện tại thời điểm onboarding. Cơ chế kiểm soát chuyển giao trả lời cho việc ai vẫn đủ điều kiện khi tài sản di chuyển. Mô hình hạ tầng thị trường riêng của Dusk coi chúng là hai giai đoạn tách biệt, và khoảng trống đó mới là phần thú vị.

Dusk liệt kê việc onboarding nhà đầu tư, “ràng buộc ví với các bên tham gia hoặc thông tin xác thực đã được xác minh,” riêng khỏi các kiểm soát chuyển giao, “thực thi ai có thể nắm giữ hoặc chuyển nhượng tài sản.” Một bên thiết lập trạng thái đủ điều kiện ban đầu. Bên còn lại mới là thứ làm cho trạng thái đó có thể được thực thi khi tài sản thực sự được chuyển.

Tài liệu XSC cũ đi xa hơn onboarding: tổ chức phát hành có thể đưa ví vào danh sách cho phép và giữ các kiểm soát ở cấp tài sản như khóa (freeze) hoặc buộc chuyển nhượng. Điều này quan trọng vì việc đủ điều kiện không chỉ được thiết lập một lần. Nó phải vẫn còn có thể được thực thi sau quyết định ban đầu.

Vì vậy, “KYC đã thông qua” và “được phép nắm giữ tài sản này” là hai tuyên bố khác nhau có thể âm thầm tách rời. Một ví có thể vẫn được xác minh theo nghĩa danh tính, trong khi không còn thuộc kiểu người nắm giữ mà tài sản cụ thể này được phép có. Việc thực thi tuân thủ không dừng ở onboarding; nó phải tiếp tục xuyên suốt vòng đời chuyển nhượng của tài sản.

“Qua kiểm tra tuân thủ và vẫn còn đủ điều kiện là hai tuyên bố khác nhau.”

Điều đó làm thay đổi câu hỏi đánh giá thực tế. Không phải “tài sản này có các kiểm tra đủ điều kiện hay không.” Câu hỏi thực sự là trạng thái đủ điều kiện hiện tại có được thực thi khi tài sản được chuyển hay không, hay việc trạng thái onboarding ban đầu chỉ đơn giản được giữ nguyên.

Thứ tôi thực sự muốn thấy: một ví mà điều kiện đủ tư cách thay đổi sau onboarding—ví dụ do thay đổi khu vực/quyền tài phán—trong khi vẫn đang nắm giữ tài sản, sau đó thực hiện một lệnh chuyển nhượng, và kiểm tra xem logic chuyển nhượng của tài sản có bắt được sự thay đổi đó hay không.

#dusk $DUSK @Dusk

Tôi đã cho rằng “thị trường lãi suất cố định” nghĩa là một mức lãi suất duy nhất: bạn biết con số trước khi giao dịch, hết. Nhưng khi nhìn kỹ cách TermMax thực sự định giá một khoản vay, giả định đó không đúng.

Lãi suất không được báo dưới dạng một con số duy nhất. Chúng được xác định thông qua các đường cong. Trong Lệnh Theo Phạm Vi Cấp (Lending Range Order), đường cong có thể bắt đầu ở một mức lãi suất thấp hơn rồi tăng dần lên khi có nhiều phần của lệnh được khớp, tương tự như AMM di chuyển qua các mức giá khác nhau thay vì đưa ra một mức giá duy nhất. Một thị trường có thể đồng thời giữ nhiều lệnh theo phạm vi, nên các bên tham gia khác nhau có thể khớp ở những điểm khác nhau trên đường cong.

Điểm khác biệt mà tôi thiếu là ở chỗ: thị trường không có một lãi suất cố định duy nhất. Mỗi vị thế được thực hiện sẽ nhận một mức lãi suất cố định được xác định bởi vị trí khớp của nó trên đường cong. Khi đã khớp, mức lãi suất đó vẫn được giữ cố định trong suốt kỳ hạn.

Đường cong cũng không phải là thứ “tuỳ ý” được tạo ra tại thời điểm chạy. Các hành động của Curator nằm trong các ràng buộc của giao thức như các thị trường được cấp phép (whitelisted) và các thay đổi được khóa theo thời gian (timelocked changes).

Vì vậy, khi TermMax gọi đó là “thị trường lãi suất cố định”, câu hỏi thú vị không chỉ là lãi suất cố định là bao nhiêu. Mà là: bao nhiêu phần của mức lãi suất đó được quyết định bởi đường cong, và bao nhiêu phần phụ thuộc vào việc thanh khoản của bạn thực sự được khớp ở đâu?

#termmax @TermMax

Hỏi hầu hết những người đánh giá một chuỗi quyền riêng tư liệu nó có riêng tư hay không, họ sẽ chỉ chọn một ô: có hoặc không. Với Dusk, đây là câu hỏi sai, và phần mô tả riêng của chính Dusk trên Hedger cho thấy vì sao.

Zedger, giao thức bảo vệ quyền riêng tư gốc của Dusk, có thể cung cấp ẩn danh hoàn toàn. Hedger, được xây dựng cho DuskEVM, thì không. Dusk nói thẳng: mô hình tài khoản dựa trên EVM ngăn cản ẩn danh hoàn toàn, trong khi Hedger giữ chi tiết giao dịch ở dạng được mã hoá bằng mã hoá đồng cấu (homomorphic encryption) và các bằng chứng không kiến thức (zero-knowledge proofs) nhưng không cung cấp cùng cam kết ẩn danh hoàn toàn đó.

Điều này không phải là một lỗi mà Dusk đang che giấu. Đây là sự đánh đổi mà kiến trúc thể hiện một cách rõ ràng: tương thích EVM đi kèm một cam kết về quyền riêng tư khác với ẩn danh hoàn toàn của Zedger.

Dưới đây là điều thực sự thay đổi khi sự đánh đổi ấy được áp dụng. Điểm khác biệt quan trọng không chỉ là liệu chi tiết giao dịch có được mã hoá hay không. Mấu chốt là cam kết về ẩn danh. Dùng nhánh Zedger và có thể có ẩn danh hoàn toàn. Dùng nhánh Hedger tương thích EVM và cam kết đó không còn. Cùng một thương hiệu, cùng từ “confidential,” nhưng bên dưới là những cam kết khác nhau.

Điều này làm thay đổi câu hỏi thực sự cần đặt ra cho bất kỳ ai đang đánh giá vấn đề này. Không phải “Dusk có hỗ trợ giao dịch confidential không.” Cả hai nhánh đều hỗ trợ luồng giao dịch riêng tư, nhưng chúng không cung cấp cùng cam kết về ẩn danh. Câu hỏi đúng là liệu cam kết mà một tài sản được quản lý nhận được có thực sự khớp với những gì quy trình của nó cần ngay từ đầu hay không.

“Quyền riêng tư giúp giữ bí mật chi tiết giao dịch và quyền riêng tư cung cấp ẩn danh hoàn toàn là hai cam kết khác nhau, ngay cả khi một dự án phát hành cả hai dưới cùng một từ.”

Thứ tôi thực sự muốn thấy là: một chứng khoán/tài sản được quản lý thực sự dùng nhánh quyền riêng tư nào trong Dusk Trade, và quy trình đó yêu cầu nhánh đó phải giữ bí mật những gì.

#dusk $DUSK @Dusk

Tôi đã cho rằng việc staking trên một chuỗi PoS có nghĩa là một khóa kiểm soát một thứ: đưa DUSK vào, nhận phần thưởng ra, và cùng một khóa xử lý toàn bộ quy trình từ đầu đến cuối.

Tài liệu vận hành của Dusk lại tách điều đó thành hai phần.

Khóa đồng thuận là khóa mà một node dùng để ký và bỏ phiếu trong cơ chế đồng thuận. Nó phải tồn tại trên một node có kết nối internet và tham gia khi trình xác thực (validator) vận hành. Khóa chủ sở hữu là một khóa riêng: đó là khóa có thể hủy staking hoặc rút tiền, và theo tài liệu thì khóa này không cần phải chạm vào node nào cả.

Lợi ích bảo mật không chỉ đơn giản là có hai khóa. Điểm mấu chốt là thẩm quyền tham gia vào đồng thuận và thẩm quyền rút quỹ không cần phải nằm ở cùng một nơi. Nếu khóa đồng thuận bị xâm phạm vì máy chủ nơi nó được đặt bị tấn công xâm nhập, kẻ tấn công có thể can thiệp vào việc tham gia đồng thuận, nhưng họ vẫn không thể hủy staking hay rút phần stake. Thẩm quyền đó ngay từ đầu đã không nằm trên máy vốn đang bị phơi ra trước Internet. Điều đó có nghĩa là câu hỏi bảo mật thực sự không chỉ là số lượng stake bao nhiêu. Mà là thẩm quyền rút stake thực sự được đặt ở đâu, so với máy đang bị kẻ tấn công nhắm tới.

Nhưng có một điểm “bẫy” mà tài liệu không hề giấu: sự tách biệt này không phải là mặc định. Nếu bạn stake mà không chỉ định một khóa chủ sở hữu tách riêng, thì khóa đồng thuận sẽ tự động trở thành khóa chủ sở hữu luôn—một khóa, một ranh giới, quay lại mô hình mà tôi đã giả định ban đầu. Thiết lập an toàn hơn là một lựa chọn mà người vận hành phải chủ động thực hiện, chứ không phải điều giao thức ép buộc.

"Một ranh giới bảo mật cần phải được chủ động bật vào là một đảm bảo khác so với ranh giới được tích hợp sẵn trong đường đi mặc định, ngay cả khi cả hai về mặt kỹ thuật đều có sẵn."

Điều tôi thực sự muốn biết là: có bao nhiêu trình cung cấp (provisioners) đang hoạt động chạy với một khóa chủ sở hữu tách riêng so với mặc định? Vì con số đó sẽ cho tôi biết ranh giới mạnh hơn có thực sự đang được áp dụng hay chỉ đơn thuần là được cung cấp.

#dusk $DUSK @Dusk

Tôi đã cho rằng một vị thế cố định có kỳ hạn bị khóa nghĩa chính xác là như vậy: bị khóa, chấm hết, cho đến khi đáo hạn. Sau đó tôi phát hiện Smart Unwind của TermMax và nghĩ rằng nó chỉ đơn giản là giải quyết điều đó. Nhưng nó không hoạt động theo cách tôi kỳ vọng.

Smart Unwind không “hút” thanh khoản thoát khỏi một pool. Nó hoạt động bằng cách làm cho vị thế của bạn đủ hấp dẫn để có người khác muốn nhận lại nó. Một leverager đặt mục tiêu APR hoặc giá. Nếu tài sản thế chấp tăng giá đủ, một arbitrageur sẽ mua vị thế theo đúng mức giá cố định đó và bán tài sản thế chấp trên thị trường mở để kiếm lời. Nếu lãi suất vay tăng, một leverager mới có thể sẽ tiếp quản vị thế với mức phí bảo hiểm thay vì mở một vị thế mới.

Vì vậy, giao thức không hề cam kết việc thoát. Việc thoát phụ thuộc vào việc có ai đó thấy giao dịch đủ hấp dẫn để đứng ra thực hiện.

Đó là phần tôi chưa cân nhắc: những điều kiện mà một leverager muốn thoát nhất—giá tài sản thế chấp giảm hoặc thị trường đang căng thẳng—có thể lại là những điều kiện mà arbitrageur không còn lợi thế tăng giá để khai thác, và cũng không có lý do để một leverager mới nhận lấy một vị thế thua lỗ. Cơ chế có thể hoạt động tốt nhất đúng vào lúc bạn ít cần đến nó nhất, và “im lặng” đúng vào lúc bạn cần nhất.

Smart Unwind cũng chưa được triển khai trực tiếp, vì vậy chưa có hành vi quan sát được; đây chỉ là những gì thiết kế ngụ ý.

Một cơ chế thoát phụ thuộc vào động cơ của người khác liệu có thật sự giải quyết tính kém thanh khoản của các vị thế cố định theo kỳ hạn, hay nó chỉ chuyển dịch cùng một vấn đề sang người cần phải được tìm thấy ở phía bên kia?

#termmax @TermMax

Tôi đã nhìn vượt qua nhãn “cho vay lãi suất cố định” của TermMax để xem thực sự bên dưới đang diễn ra điều gì.

Thứ nguyên thủy này trông ít giống một pool cho vay với APY cố định và nhiều hơn như một thị trường thu nhập cố định onchain. FT của nó là một token kiểu trái phiếu không trả lãi (zero-coupon): người cho vay mua với giá thấp hơn mệnh giá và nhận hoàn trả theo mệnh giá khi đáo hạn, với lợi suất được cố định tại thời điểm tham gia. Điều này làm tôi nghĩ khác về sản phẩm: lãi suất cố định không chỉ là một tham số của một pool cho vay. Nó được nhúng trong một quyền đòi hỏi gắn với thời hạn đáo hạn.

Vào tháng Một, cùng mô hình lãi suất cố định đã mở rộng vượt ra ngoài tài sản thế chấp “native” trong crypto sang các chứng khoán được token hóa, với việc triển khai vay với lãi suất cố định dựa trên cổ phiếu đã được token hóa của Ondo Global Markets.

Lãi suất cố định loại bỏ sự không chắc chắn về lãi suất trong suốt kỳ hạn. Nó không loại bỏ nhu cầu tái cấp vốn khi kỳ hạn kết thúc. TermMax đã có tính năng “lăn kỳ” một chạm: chuyển sang đáo hạn cố định muộn hơn hoặc sang các thị trường lãi suất biến đổi của Morpho, vì vậy giao thức đã thiết kế rõ ràng cho bước tái cấp vốn đó. Thứ được ghi chép tốt là kiến trúc; thứ còn thiếu là dữ liệu về cách lộ trình này vận hành khi nhiều vị thế cần được lăn kỳ cùng lúc trong trạng thái căng thẳng.

Với hơn $90M TVL trên 10 chuỗi EVM và mốc TGE của $TMX được đặt vào ngày 25 tháng Tám, đây là phần tôi sẽ theo dõi tiếp.

#termmax @TermMax

Tôi đã kỳ vọng rằng "các kiểm tra tính đủ điều kiện" đứng sau Dusk Trade sẽ là một thứ được xây dựng riêng cho hoạt động giao dịch. Một mô-đun tuân thủ được gắn thêm vào lớp sàn giao dịch, giống như cách hầu hết các broker tích hợp KYC trực tiếp vào chính nền tảng.

Nhưng không phải vậy.

Lớp định danh mà Dusk Trade dựa vào được gọi là Citadel, và nó không bắt đầu như một tính năng phục vụ giao dịch. Dusk đã ra mắt nó vào tháng 1 năm 2023 như một giao thức KYC/định danh dựa trên kiến thức bằng không (zero-knowledge): chứng minh rằng bạn sở hữu một chứng chỉ hợp lệ mà không tiết lộ nội dung của nó, rồi tái sử dụng bằng chứng đó giữa nhiều dịch vụ thay vì mỗi lần lại gửi lại dữ liệu của bạn.

Mốc thời gian đó khiến tôi đọc cách hiểu về "các kiểm tra tính đủ điều kiện" trong tài liệu theo một hướng khác. Nó giống ít hơn với kiểu tuân thủ được làm riêng cho một sản phẩm cụ thể, và giống hơn với một “nguyên ngữ/tiện ích” về định danh đã có từ trước sản phẩm mà nó được dùng kèm.

Phần đáng chú ý là Citadel được thiết kế để phục vụ các nhà cung cấp dịch vụ vượt ra ngoài một luồng giao dịch đơn lẻ. Dusk mô tả nó như một lớp định danh mà các công ty có thể tận dụng để xác minh liệu một người có đáp ứng các tiêu chí của họ hay không, mà không cần nắm giữ quyền quản lý toàn bộ dữ liệu định danh nằm bên dưới.

"Một kiểm tra tính đủ điều kiện được xây cho một sản phẩm, và một lớp định danh được thiết kế để vượt qua tuổi thọ của chính sản phẩm đó—dù người dùng có thể trải nghiệm cả hai như việc 'chứng minh bạn là ai'—vẫn là hai loại hạ tầng khác nhau."

Thứ tôi thực sự muốn thấy: một chứng chỉ được chứng minh thông qua Citadel và được một nhà cung cấp dịch vụ khác chấp nhận bên ngoài Dusk Trade, bằng chứng cho thấy “nguyên ngữ định danh dùng chung” từ một mô tả mang tính kiến trúc đã trở thành khả năng tái sử dụng xuyên dịch vụ được chứng minh.

#dusk $DUSK @Dusk

Tôi đã nghĩ rằng “Dusk hợp tác với Chainlink” có nghĩa là phần giới thiệu quen thuộc. Một cây cầu. Token di chuyển qua các chuỗi. Câu chuyện chuẩn về khả năng tương tác mà cuối cùng mọi dự án đều công bố.

Nhưng đó chỉ là phần nhỏ.

Được công bố từ tháng Mười Một, thỏa thuận này ghép Chainlink CCIP làm lớp khả năng tương tác cho các chứng khoán token hóa của NPEX với một thứ dễ lướt qua: Chainlink DataLink trở thành oracle dữ liệu onchain độc quyền cho NPEX. Không phải một trong nhiều nguồn cấp giá. Mà là nguồn cấp độc quyền. Cùng thỏa thuận đó cũng cho phép chính DUSK tự di chuyển theo cách gốc giữa Ethereum và Solana thông qua chuẩn CCT của Chainlink, nên token cũng có luôn câu chuyện “cây cầu”.

Chín tháng sau, đó là phần đáng tách riêng. CCIP giúp một tài sản di chuyển qua các hệ sinh thái. DataLink cung cấp dữ liệu thị trường của NPEX mà hệ thống nhận có thể dựa vào. Một bên nói về mức độ tiếp cận. Bên kia nói về việc ai được phép được tin cậy. Bất kỳ chuỗi nào tiêu thụ dữ liệu NPEX đó đều đang xây dựng trên cùng một nguồn dữ liệu thị trường chính thức.

Tôi không nghĩ đó là một khiếm khuyết tự động. Thị trường được quản lý đã và đang phụ thuộc vào các nguồn dữ liệu thị trường mang tính thẩm quyền. Nhưng điều đó có nghĩa rằng tính “tương thích/lắp ghép” xuyên chuỗi ở đây không phải là hạ tầng trung lập hoàn toàn. Đó là khả năng lắp ghép được xây dựng quanh một nguồn độc quyền cho dữ liệu thị trường chính thức của NPEX, dù dữ liệu đó cuối cùng được đọc ở bất kỳ nơi nào.

“Khả năng chuyển một tài sản qua các chuỗi và trở thành nguồn độc quyền cho dữ liệu thị trường chính thức của nó là hai dạng quyền lực khác nhau, ngay cả khi một thỏa thuận lại trao cả hai.”

Thứ tôi thực sự muốn biết sau chín tháng là: chuyện gì xảy ra trên các chuỗi khác nếu nguồn dữ liệu độc quyền của NPEX đó trở nên không sẵn sàng hoặc bị tranh chấp, và liệu “có thể lắp ghép” một cách lặng lẽ có nghĩa là “phụ thuộc vào một đường dây độc quyền quay ngược về NPEX” hay không.

#dusk $DUSK @Dusk

Trước đây tôi nghĩ token hóa và phát hành bản địa chỉ là hai cách khác nhau để đưa một tài sản lên onchain. Trang so sánh của Dusk đã thay đổi cách nhìn đó. Chúng không phải là hai mức độ của cùng một thứ. Chúng là hai kiến trúc hoàn toàn khác nhau.

Theo định nghĩa riêng của Dusk, token hóa phát hành một token đại diện cho một tài sản hoặc một yêu cầu đối với tài sản đó, trong khi bản thân tài sản gốc vẫn có thể gắn với bất kỳ quy trình lưu ký, đăng ký và thanh toán nào đang chạy off-chain trước đó. Token chỉ là một bản đại diện, không phải chính tài sản gốc. Phát hành bản địa loại bỏ lớp đó: tài sản tồn tại ngay trên on-chain như chính nó, và vòng đời của nó—được phát hành, chuyển nhượng, quản lý, thanh toán—không cần một bản ghi tách biệt nào đó khác để chỉ quay lại.

Điểm “vướng” là một token vẫn có thể phụ thuộc vào một hệ thống khác để hệ thống đó tiếp tục là nguồn dữ liệu sự thật (truth) thực sự. Nếu sổ đăng ký off-chain đó bị chậm trễ hoặc hỏng, thì cam kết của token chỉ mạnh đến mức khả năng đối soát (reconciliation) phía sau nó.

Đây là chỗ mọi thứ mang tính điều kiện. Bản so sánh của Dusk nói rằng phát hành bản địa có thể giảm sự phụ thuộc vào các lớp lưu ký và đăng ký riêng, "tùy thuộc vào cấu trúc pháp lý". Cụm điều kiện này đang làm phần lớn công việc trong luận điểm này. Lập luận về hiệu quả không đến từ việc công nghệ tồn tại. Nó phụ thuộc vào việc cấu trúc pháp lý thực sự cho phép bản ghi on-chain gánh vác trọng trách đó, thay vì chỉ là một bản sao khác của “bản ghi thực”.

"Một token đại diện cho một tài sản và một tài sản tồn tại dưới dạng token là hai lời hứa khác nhau, ngay cả khi cả hai đều được bán như là token hóa."

Thực ra, thứ tôi muốn thấy trước khi gọi điều này là “thật sự”: một chứng khoán đã được quản lý, nơi bản ghi mang tính quyết định (authoritative record) nằm trên onchain, chứ không phải một lớp thanh toán chạy song song với một sổ đăng ký vẫn giữ quyền quyết định cuối cùng.

#dusk $DUSK @Dusk

Tôi thấy mình cứ nhìn chằm chằm vào trình khám phá testnet của DuskEVM, và con số nổi bật—845,113 giao dịch trên 282 địa chỉ ví—gần như là “con số sai” để tập trung. Ước tính khoảng 3,000 giao dịch cho mỗi địa chỉ, một tỷ lệ nói lên ít hơn về mức độ chấp nhận so với tiêu đề gợi ý.

Hai giao dịch gần đây nhất đều có Value 0 DUSK: phí đã trả, không có giá trị bản địa nào được chuyển đi. Mục cấp dữ liệu mới nhất được gắn nhãn là L1→L2 deposit (nạp từ L1 sang L2). Chưa phải bằng chứng cho thấy 845K giao dịch còn lại trông như thế nào, nhưng cũng đủ để tôi dừng việc coi đây là chỉ “một con số”. Thứ mà trình khám phá thực sự hiển thị đầu tiên chính là hoạt động mạng: chuỗi đang xử lý giao dịch. Việc liệu có bất kỳ phần nào là hoạt động kinh tế—giá trị thực sự được chuyển qua vì một lý do nào đó—là một câu hỏi khác, mà số lượng giao dịch không thể tự trả lời được.

Sự phân biệt này quan trọng vì Dusk cuối cùng đang định vị hạ tầng này cho các tài sản tài chính được quản lý, và chính xác là điều mà kế hoạch của Dusk nhằm đưa 300M€ tài sản NPEX lên onchain sau này sẽ cần chứng minh. Một chuỗi bận rộn và một chuỗi mang khối lượng thanh toán thực có thể tạo ra trang thống kê trông giống hệt.

"Hoạt động mạng không phải là cùng một khẳng định với hoạt động tài chính, ngay cả khi cả hai đều hiện lên dưới dạng một con số duy nhất trên trình khám phá."

Thứ tôi thực sự sẽ theo dõi như một tín hiệu cho thấy nó chuyển từ hoạt động mạng sang sử dụng cho mục đích tài chính: mức độ trong đó phản ánh giá trị kinh tế thực sự đã được thanh toán, khi NPEX cho chúng ta một thứ cụ thể để đối chiếu.

#dusk $DUSK @Dusk

Bài viết riêng của Dusk về Hedger cho thấy việc tạo bằng chứng phía máy khách dưới 2 giây. Đọc lại hai lần trước khi nó kịp lắng xuống. Nhanh đến mức cụm “confidential phải chậm hơn” không còn cảm giác như một giả định an toàn nữa. Mình bắt đầu đào sâu xem rốt cuộc những gì đang được chứng minh nhanh đến vậy. Testnet công khai của DuskEVM đã hoạt động từ tháng Mười Hai, và vài ngày trước Dusk Foundation đã mở nó cho việc kiểm thử với Solidity và Hardhat — đây là bản cập nhật mà thực sự mình đang đọc. Câu khiến mình dừng lại: “tính đủ điều kiện được kiểm tra trước khi truy cập hoặc chuyển giao”. Ban đầu mình nghĩ đó là phần tuân thủ thú vị. Mình để mở nguyên ở một tab trong lúc đi lấy cà phê, quay lại, đọc lại và nhận ra là không phải. Dusk nói rằng dữ liệu người tham gia, số dư và số tiền chuyển có thể vẫn được mã hóa. Đó là phần thực sự làm mình chú ý — khoảng trống giữa việc chứng minh bạn được phép vào, và việc lộ ra bạn đang mang theo gì sau khi bạn được phép. Bước kiểm tra tính đủ điều kiện đúng như trong tài liệu — được định nghĩa rõ ràng, không chỉ là một lời khẳng định tuân thủ chung chung. Mình vẫn không tìm được một ví dụ cụ thể về việc một bên xem xét được ủy quyền thực sự sẽ thấy gì khi dùng đường kiểm toán đó. Mình đã xem tài liệu hai lần. Vài ngày sau khi mở cho Solidity/Hardhat, tò mò không biết liệu ví dụ đó có xuất hiện khi mọi thứ dần trưởng thành hay không, hay “auditable” chỉ vẫn là một từ mà không ai phải chứng minh ngay — ở đây hay trên bất kỳ chuỗi nào đưa ra cùng một khẳng định.

#dusk $DUSK @Dusk

Tối nay tôi vừa xem biểu đồ của BABY chỉ để kiểm tra còn bao nhiêu ngày trước khi mở khóa, và điều nổi bật không phải là phần đếm ngược.

Ngày 10 tháng 8. Còn 5 ngày nữa. 136,11M token, khoảng 1,43 triệu USD, 1,2% tổng cung — phần lớn chuyển đến đội ngũ, cố vấn và nhà đầu tư ở vòng đầu — các con số y hệt mà bất kỳ ai theo dõi cũng đã biết.

Thứ tôi thực sự chưa xem là bảy ngày trước đó.

BABY giảm khoảng 10,3% trong tuần này. Giá hiện quanh 0,0105 USD, vốn hóa khoảng 45 triệu USD, kém hiệu suất hơn toàn bộ thị trường crypto, mà trên thực tế trong giai đoạn tương tự vẫn gần như đi ngang.

Lần đọc đầu tiên của tôi là, được rồi, chắc là việc bán do mở khóa bắt đầu từ sớm.

Có thể không. Có thể là điều kiện thị trường rộng hơn không liên quan gì đến ngày 10 tháng 8. Tôi không có cách nào để tách bạch “người ta mua bán trước để đón mở khóa” với việc “BABY chỉ đang có một tuần tệ cùng với mọi thứ khác.”

Dù sao đi nữa, các token rơi vào các ví đó vào ngày 10 tháng 8 sẽ đến với một mức giá đã giảm 10% so với một tuần trước.

Ai bán trong tuần này đã bán vào đúng lúc giá rơi. Ai nhận mở khóa thì lại bán vào phần còn lại sau đó.

Hai phía khác nhau của cùng một giai đoạn năm ngày — mỗi bên hấp thụ một nửa diễn biến.

Tôi không biết liệu lần này mẫu hình đó có lặp lại không. Những gì tôi đọc chưa có phần phân tích chi tiết bao nhiêu trong các lần mở khóa Babylon trước đó đã được định giá trước, so với việc phản ứng sau.

Nếu giá đã dịch chuyển trước khi ngày mở khóa diễn ra, thì ngày mở khóa bản thân nó còn tiết lộ được gì?

@BabylonLabs_io #baby $BABY