I only went looking because I tried to move $DUSK through the bridge and ended up reading the incident history instead.
On January 16, 2026, an attacker gained access to a signing wallet used by Dusk's bridge service. @Dusk described suspicious activity around a team-managed operational wallet, then disabled and recycled related addresses, paused the bridge, and coordinated with Binance.
They also added a recipient blocklist to the Web Wallet to prevent transfers to compromised, scam-related or sanctioned addresses.
Dusk said this was not a consensus failure or protocol-level exploit of DuskDS, and that user funds were not affected.
I read that in two ways.
First, the response was a positive signal. They detected abnormal behaviour, shut down the risky path, disclosed the incident, and later published a detailed post-mortem instead of stopping at "funds are safe."
For an early-stage network, that matters. Speed of containment and clarity of disclosure are part of the security record too.
But the second part is harder to ignore.
The bridge relied on a signing wallet inside a team-managed operational path. Dusk's post-mortem said the original design prioritised speed and simplicity, but concentrated too much trust in one path. Once that signing path was compromised, the attacker did not need to break Dusk consensus.
That sits awkwardly beside Dusk's DuskDS ↔ DuskEVM "trustless native bridge" direction. A protocol can be decentralized while infrastructure above it still has human choke points.
To Dusk's credit, the bridge was redesigned: signing was separated from event handling, fund release from event ingestion, hot-wallet exposure was reduced, and the service was isolated more aggressively.
Current docs describe bridge flows between Dusk mainnet and BSC, so calling the January shutdown "still closed" would be outdated.
So the real question is:
Does the speed and detail of Dusk's response build more trust, or does one team-operated signing path holding that much authority remain the bigger concern?
#dusk $DUSK @Dusk
On January 16, 2026, an attacker gained access to a signing wallet used by Dusk's bridge service. @Dusk described suspicious activity around a team-managed operational wallet, then disabled and recycled related addresses, paused the bridge, and coordinated with Binance.
They also added a recipient blocklist to the Web Wallet to prevent transfers to compromised, scam-related or sanctioned addresses.
Dusk said this was not a consensus failure or protocol-level exploit of DuskDS, and that user funds were not affected.
I read that in two ways.
First, the response was a positive signal. They detected abnormal behaviour, shut down the risky path, disclosed the incident, and later published a detailed post-mortem instead of stopping at "funds are safe."
For an early-stage network, that matters. Speed of containment and clarity of disclosure are part of the security record too.
But the second part is harder to ignore.
The bridge relied on a signing wallet inside a team-managed operational path. Dusk's post-mortem said the original design prioritised speed and simplicity, but concentrated too much trust in one path. Once that signing path was compromised, the attacker did not need to break Dusk consensus.
That sits awkwardly beside Dusk's DuskDS ↔ DuskEVM "trustless native bridge" direction. A protocol can be decentralized while infrastructure above it still has human choke points.
To Dusk's credit, the bridge was redesigned: signing was separated from event handling, fund release from event ingestion, hot-wallet exposure was reduced, and the service was isolated more aggressively.
Current docs describe bridge flows between Dusk mainnet and BSC, so calling the January shutdown "still closed" would be outdated.
So the real question is:
Does the speed and detail of Dusk's response build more trust, or does one team-operated signing path holding that much authority remain the bigger concern?
#dusk $DUSK @Dusk