#dusk $DUSK @Dusk I looked through Dusk's whitepaper table of contents this week — page 2 of 22, nothing more than the outline. But the structure told me something. Section 4, "Transactions," splits into two: Moonlight (page 13) and Phoenix (page 14). Two transaction models in the same document.

I'll be upfront about what I actually know versus what I'm guessing. From the TOC alone, I can confirm Dusk documents two transaction types under one chain. I have not read the full text of those sections, so I can't verify with certainty how they differ mechanically — I'm inferring, based on the naming convention and general industry patterns, that one is likely transparent/account-based and the other privacy-preserving. That's an assumption, not a confirmed fact from this source.

What is confirmed by the TOC: consensus gets six full subsections (3.1–3.9, pages 6–11) — provisioners, committees, attestations, sortition, emergency mode, fallback, rolling finality, incentives. That's a dense structure for finality alone. I can't verify from a table of contents whether this design has been tested under adversarial conditions at scale — that would require the actual technical content, audits, or mainnet data, none of which I have in front of me right now.

So here's my honest position: the paper's structure suggests deliberate separation between transparent and confidential transaction handling, which matters for regulated finance use cases. But claims about fault tolerance or committee resilience need independent verification — audits, incident history, or third-party review — before I'd treat them as settled.

Has anyone actually seen Dusk's consensus mechanism reviewed by an independent security audit, or is that still outstanding? $TAC.US
$SOON