I’ve been watching privacy chains long enough to know the real friction isn’t just hiding amounts. It’s what happens when the chain starts chasing EVM compatibility. Most projects treat that as pure upside—more developers, familiar wallets, existing tools. I’ve seen how quickly that convenience starts shaping the privacy design itself.

Dusk is interesting because it doesn’t pretend the two models can be forced together. DuskDS keeps the Phoenix UTXO approach for native shielded transfers. Notes, nullifiers, zero-knowledge proofs that actually conceal the graph. On the EVM side they built Hedger instead: homomorphic encryption to hide values, proofs to show the computation still checks out. Official docs are surprisingly honest about the limit—EVM’s account model simply can’t deliver the same anonymity set Phoenix does.

That honesty is rare. Most teams paper over the trade-off. You want Solidity, MetaMask, the whole stack, so you accept that full transaction graph privacy is gone and try to recover what you can with encrypted balances and selective disclosure. The question becomes whether the privacy standard holds across both execution environments, or whether one quietly becomes the weaker sibling.

I’m not sure yet. I’ve watched too many projects claim “privacy-preserving EVM” and end up with something that only hides the numbers while the addresses and interaction patterns stay public. The hard part has always been proving the result is valid without leaking the inputs. Phoenix does it one way. Hedger tries another. Both have to answer the same quiet problem that keeps showing up after every cycle: how much privacy survives once you start making the chain convenient for everyone else.
@Dusk_Foundation #dusk $DUSK