An uncomfortable fact is more useful than a comfortable one, so here is an uncomfortable fact about Dusk Network: an internal audit completed in early 2026 found 39 issues in its production codebase, seven of them critical, more than a year after mainnet had already been processing real value.
The four root causes behind those critical findings are worth naming plainly rather than smoothing over. Two came from unsound memory ownership in Piecrust, the virtual machine sandbox, that could let two honest nodes execute identical code and quietly compute different results, a defect category that is worse than a crash because it can stay invisible. One came from a host side deserialization path that trusted contract controlled bytes without validating them first, turning a contract level bug into a node integrity problem. Another sat in how Phoenix, the shielded transaction model, bound its fee and refund logic, a gap that on its own opened paths toward supply inflation, chain halts, and refund redirection all at once. The last was a cryptographic construction weakness in the BLS signature scheme sitting under consensus authentication itself. Investigating prior exploitation meant combing through logs and host level evidence across the whole stack, not just checking for one bug pattern in a transaction history.
Dusk says its own investigation found no evidence any of the seven were exploited before the fix shipped as a hard fork in March 2026, its largest release since launch. I have no way to independently confirm that claim, and neither does anyone reading this, though with NPEX alone planning to move over 300 million euros onto this codebase, the stakes for getting it right were never small. What I do take from it is more mixed than pure reassurance: catching this before exploitation is genuinely good work, but it also means code this consequential ran in production for over a year carrying flaws nobody had found yet. One clean audit is a milestone. It is not the same as an ongoing guarantee.
@Dusk $DUSK #dusk
The four root causes behind those critical findings are worth naming plainly rather than smoothing over. Two came from unsound memory ownership in Piecrust, the virtual machine sandbox, that could let two honest nodes execute identical code and quietly compute different results, a defect category that is worse than a crash because it can stay invisible. One came from a host side deserialization path that trusted contract controlled bytes without validating them first, turning a contract level bug into a node integrity problem. Another sat in how Phoenix, the shielded transaction model, bound its fee and refund logic, a gap that on its own opened paths toward supply inflation, chain halts, and refund redirection all at once. The last was a cryptographic construction weakness in the BLS signature scheme sitting under consensus authentication itself. Investigating prior exploitation meant combing through logs and host level evidence across the whole stack, not just checking for one bug pattern in a transaction history.
Dusk says its own investigation found no evidence any of the seven were exploited before the fix shipped as a hard fork in March 2026, its largest release since launch. I have no way to independently confirm that claim, and neither does anyone reading this, though with NPEX alone planning to move over 300 million euros onto this codebase, the stakes for getting it right were never small. What I do take from it is more mixed than pure reassurance: catching this before exploitation is genuinely good work, but it also means code this consequential ran in production for over a year carrying flaws nobody had found yet. One clean audit is a milestone. It is not the same as an ongoing guarantee.
@Dusk $DUSK #dusk