Everyone who’s done a compliance audit has a common feeling: the thing to fear isn’t the inspection itself—it’s having to prove that a customer hasn’t violated any rules while also not exposing the customer’s privacy in full. Traditional approaches rely on reviewing bank flow records, identity documents, and address proofs; after the audit, everything still has to be archived. Every archived record is a risk.
So when I look at projects like Dusk that play the “compliance and privacy” card, my first reaction is to see how they handle this contradiction. With Citadel’s identity layer, it takes a selective disclosure route: users hold credentials issued by an institution, and during transactions they use zero-knowledge proofs—cryptographic tools that don’t reveal specific information, but can prove that “I meet the requirements.” This proves compliance without having to hand over originals. Moonlight handles ordinary transfers with publicly available accounts. Phoenix uses private UTXOs—similar to Bitcoin’s unspent transaction output model—so each transaction is isolated, doesn’t expose balances, and can handle sensitive transactions by splitting the two paths. @Dusk
For regulated assets, this logic holds: asset transfers must pass compliance checks and also protect privacy—you can’t throw away KYC for the sake of privacy.
I won’t sugarcoat it. Citadel’s root of trust is tied to the issuer. Who is authorized to issue, how credentials get revoked, and whether old credentials still count if an institution disappears—these aren’t problems cryptography can solve; they’re governance issues. Flip through the documentation and you’ll find the revocation mechanism details are thin. Cross-jurisdictional use is also a problem: the EU definition of qualified investors differs from the U.S., so credentials can’t be reused directly. A crypto-library vulnerability was patched in April 2026, but it makes you ask one more question: are there any other issues?
The ecosystem is thin too. GitHub updates are slow, there are few third-party applications, and the documentation isn’t beginner-friendly. The technical direction is sound, but no one is building the infrastructure—good foundations don’t matter if the space is empty.
My view: Dusk has tackled the technical challenge of “compliance and privacy at the same time,” and the direction is right. What’s left is all business negotiation and regulatory communication—things that take far longer than writing code.
If you want licensed institutions to give up the customer-data moat they already have, what can you offer that actually gets them to talk? #dusk $DUSK
So when I look at projects like Dusk that play the “compliance and privacy” card, my first reaction is to see how they handle this contradiction. With Citadel’s identity layer, it takes a selective disclosure route: users hold credentials issued by an institution, and during transactions they use zero-knowledge proofs—cryptographic tools that don’t reveal specific information, but can prove that “I meet the requirements.” This proves compliance without having to hand over originals. Moonlight handles ordinary transfers with publicly available accounts. Phoenix uses private UTXOs—similar to Bitcoin’s unspent transaction output model—so each transaction is isolated, doesn’t expose balances, and can handle sensitive transactions by splitting the two paths. @Dusk
For regulated assets, this logic holds: asset transfers must pass compliance checks and also protect privacy—you can’t throw away KYC for the sake of privacy.
I won’t sugarcoat it. Citadel’s root of trust is tied to the issuer. Who is authorized to issue, how credentials get revoked, and whether old credentials still count if an institution disappears—these aren’t problems cryptography can solve; they’re governance issues. Flip through the documentation and you’ll find the revocation mechanism details are thin. Cross-jurisdictional use is also a problem: the EU definition of qualified investors differs from the U.S., so credentials can’t be reused directly. A crypto-library vulnerability was patched in April 2026, but it makes you ask one more question: are there any other issues?
The ecosystem is thin too. GitHub updates are slow, there are few third-party applications, and the documentation isn’t beginner-friendly. The technical direction is sound, but no one is building the infrastructure—good foundations don’t matter if the space is empty.
My view: Dusk has tackled the technical challenge of “compliance and privacy at the same time,” and the direction is right. What’s left is all business negotiation and regulatory communication—things that take far longer than writing code.
If you want licensed institutions to give up the customer-data moat they already have, what can you offer that actually gets them to talk? #dusk $DUSK