The two audits Dusk just published don't cover the thing that actually got hacked.
Both are dated April 2026, and both review the DUSK token's smart contract code the ERC-20 version on Ethereum, the BEP-20 version on BNB Chain. Useful work, and the first new audits Dusk has published in eighteen months. But the January bridge incident wasn't a contract bug. Per Dusk's own reporting, a team-managed signing wallet was compromised because of how the bridge service itself was architected signing, event handling, and network access sitting too close together, not a flaw in the token's on-chain code. A contract audit checks logic in the contract; it doesn't examine how an off-chain service manages its keys or access. Different risk category entirely, and this pair of audits doesn't touch it.
The more consequential gap sits elsewhere. DuskEVM, the EVM-compatible layer that just moved into public testnet and is the entire basis for onboarding Solidity developers, has no audit anywhere in Dusk's public repository. Not core-audits, not the new token-audits folder either. I can't confirm one doesn't exist privately only that nothing's published. That matters more than the token contracts do, because DuskEVM is the newest surface, not a rebuild of something that already failed once.
Getting audited answers "was this specific thing reviewed." It doesn't answer "is the system secure." Worth remembering before DuskEVM carries real value into mainnet.`
@Dusk #dusk $DUSK
Both are dated April 2026, and both review the DUSK token's smart contract code the ERC-20 version on Ethereum, the BEP-20 version on BNB Chain. Useful work, and the first new audits Dusk has published in eighteen months. But the January bridge incident wasn't a contract bug. Per Dusk's own reporting, a team-managed signing wallet was compromised because of how the bridge service itself was architected signing, event handling, and network access sitting too close together, not a flaw in the token's on-chain code. A contract audit checks logic in the contract; it doesn't examine how an off-chain service manages its keys or access. Different risk category entirely, and this pair of audits doesn't touch it.
The more consequential gap sits elsewhere. DuskEVM, the EVM-compatible layer that just moved into public testnet and is the entire basis for onboarding Solidity developers, has no audit anywhere in Dusk's public repository. Not core-audits, not the new token-audits folder either. I can't confirm one doesn't exist privately only that nothing's published. That matters more than the token contracts do, because DuskEVM is the newest surface, not a rebuild of something that already failed once.
Getting audited answers "was this specific thing reviewed." It doesn't answer "is the system secure." Worth remembering before DuskEVM carries real value into mainnet.`
@Dusk #dusk $DUSK
