$DUSK #dusk @Dusk

I spent the task digging through Dusk’s cryptography — Argon2, Equihash, PLONK, the whole serious-math side of the stack.

Then I checked what actually became a security problem recently.

It wasn’t the cryptography.

It was an operational wallet.

On Aug 16, Dusk paused its bridge services after monitoring flagged activity that didn’t match normal bridge operations. DuskDS itself kept producing blocks, and the mitigation that followed wasn’t a new proof system or consensus change.

It was much simpler: a recipient blocklist in the Web Wallet that warns users before sending to flagged addresses.

That contrast stuck with me.

Dusk can have sophisticated cryptography underneath, while the most immediate user-facing defense sits at the wallet layer.

And that creates an interesting boundary.

If you use the Web Wallet, you get that warning.

If you interact through your own tooling or directly through the protocol, you may not.

So the security model isn’t just about how strong the underlying cryptography is.

It’s also about where the protection actually lives — and who inherits it by default.

I can see why a wallet-level control is the fastest practical response.

But for a network targeting regulated finance, I keep coming back to one question:

How much security should live in the protocol, and how much can safely live in the interface?

$PORTAL
$PROM

Where should Dusk’s security controls live? 👀