Forging ZK proofs to mint arbitrary DUSK tokens

A one-check slip-up could’ve let anyone print fake DUSK—and the comments went feral

TLDR: Researchers say a flaw in Dusk’s proof system could have let attackers mint fake coins and fake private transfers on a network tied to about $60 million. Commenters instantly turned it into a fight over overcomplicated crypto design, missing bug bounties, and whether anyone should trust systems this fragile.

Crypto security stories usually come with a lot of math, but the comment section turned this one into a full-blown drama thread. The basic scandal: researchers say Dusk Network had a flaw so serious that someone could have created DUSK tokens out of thin air and pushed fake private transactions through the network as if everything was normal. In plain English, one crucial proof check wasn’t really checking enough—and that is exactly the sort of sentence that makes crypto people start stress-posting.

The loudest reaction was a mix of “this is why zero-knowledge crypto is terrifying” and “how on earth was there no bug bounty?”. mike_hearn used the moment to revive an old war: fancy privacy tech versus more boring secure hardware, basically saying this kind of complexity is why his team once avoided zero-knowledge proofs altogether. That sparked the classic tech-comment vibe of “maybe the clever solution is too clever.” Meanwhile, mtlynch went straight for the wallet drama, pointing out that Dusk once said a bug bounty was coming “in the near future” back in 2023—an observation that landed like a sarcastic slow clap.

And yes, there’s dark humor everywhere. The vibe was very much “privacy coin almost got an infinite money cheat code”. Beneath the jokes, though, commenters sounded genuinely rattled: if one missed check can threaten a project tied to around $60 million, people want fewer promises, more audits, and maybe a little less mathematical swagger.

Key Points

  • Researchers reported a critical soundness vulnerability in Dusk Network’s dusk-plonk verifier.
  • The verifier failed to validate four prover-supplied public selector evaluations against trusted commitments in the verifier key.
  • Because of that gap, a malicious prover could forge proofs for false statements while still passing verification.
  • On the live Rusk network, the flaw could have enabled arbitrary DUSK minting and forged shielded spends through Phoenix.
  • The article explains PLONK’s arithmetic-circuit and selector-based design to show how the unchecked evaluations undermined proof verification.

Hottest takes

"the controversial choice to not use ZKPs" — mike_hearn
"I notice no mention of a bug bounty. Did they not get paid for this?" — mtlynch
"we will certainly create an extensive one in the near future" — mtlynch
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.