I think people read “security audited” on a crypto project and immediately move on.
I don’t.
With Dusk, the interesting part isn’t the list of auditors. It’s the stuff they actually had to find.
Dusk has been reviewed across PLONK, Piecrust, Phoenix, Kadcast, BLS, consensus, Rusk and its migration contracts. On paper, that looks reassuring.
Then you remember how these systems usually break.
Not because the headline cryptography suddenly stops working.
Because two pieces of perfectly reasonable code make a bad assumption about each other.
Dusk has had examples of exactly that.
A PLONK issue once allowed the possibility of forged proofs because public inputs weren’t being handled correctly in the Fiat-Shamir transcript. It was caught and fixed.
Then AEGIS uncovered something even more interesting.
39 findings. 7 marked critical.
The scary part wasn’t the number.
It was the locations: VM isolation, host-side deserialization, Phoenix fee/refund logic, and BLS signatures.
Those are boring names until you realise each one sits near a boundary where the protocol has to trust another component.
That’s where I pay attention.
Because a ZK proof being mathematically sound doesn’t help much if the VM around it interprets state incorrectly.
A strong signature scheme doesn’t save you from a bad implementation.
And a smart contract can be perfectly written while the environment feeding it bad data.
That’s also why I’m more interested in what Dusk did after the findings.
They didn’t just patch a few lines and call it done. The fixes became tighter checks, additional regression tests, stronger decoding rules, better fee/refund binding and changes around BLS verification.
That’s the part most people skip when they talk about audits.
An audit is not proof that nothing will break.
It’s evidence of what happens when someone tries hard enough to break it.
And honestly, that’s a much more useful thing to watch.
#dusk $DUSK @Dusk
I don’t.
With Dusk, the interesting part isn’t the list of auditors. It’s the stuff they actually had to find.
Dusk has been reviewed across PLONK, Piecrust, Phoenix, Kadcast, BLS, consensus, Rusk and its migration contracts. On paper, that looks reassuring.
Then you remember how these systems usually break.
Not because the headline cryptography suddenly stops working.
Because two pieces of perfectly reasonable code make a bad assumption about each other.
Dusk has had examples of exactly that.
A PLONK issue once allowed the possibility of forged proofs because public inputs weren’t being handled correctly in the Fiat-Shamir transcript. It was caught and fixed.
Then AEGIS uncovered something even more interesting.
39 findings. 7 marked critical.
The scary part wasn’t the number.
It was the locations: VM isolation, host-side deserialization, Phoenix fee/refund logic, and BLS signatures.
Those are boring names until you realise each one sits near a boundary where the protocol has to trust another component.
That’s where I pay attention.
Because a ZK proof being mathematically sound doesn’t help much if the VM around it interprets state incorrectly.
A strong signature scheme doesn’t save you from a bad implementation.
And a smart contract can be perfectly written while the environment feeding it bad data.
That’s also why I’m more interested in what Dusk did after the findings.
They didn’t just patch a few lines and call it done. The fixes became tighter checks, additional regression tests, stronger decoding rules, better fee/refund binding and changes around BLS verification.
That’s the part most people skip when they talk about audits.
An audit is not proof that nothing will break.
It’s evidence of what happens when someone tries hard enough to break it.
And honestly, that’s a much more useful thing to watch.
#dusk $DUSK @Dusk