Dusk's bridge incident from last week is actually a decent window into how DuskDS, DuskVM and DuskEVM are separated in practice, not just on paper.
On August 16, the Dusk team flagged suspicious activity on a team-managed wallet used for bridge operations, disabled the affected addresses, and paused bridge services while coordinating with Binance after part of the flow touched the exchange. What made me dig deeper: the team's own incident notice was explicit that this was a wallet-key issue, not a DuskDS protocol fault. That's a meaningful distinction architecturally the bridge sits as an operational layer on top of DuskDS's settlement, separate from the consensus and execution logic that DuskVM and DuskEVM actually run on.
Checking the sequence, the pause looks reactive rather than automated a monitoring alert triggered manual containment, not a circuit-breaker built into the protocol. That's worth noting for anyone assuming bridge security is enforced at the base-layer level here.
What I can't confirm: the exact number or value of transactions during the incident window, or whether the recycled addresses were multisig-controlled. Dusk's notice states no user funds were affected, but I haven't seen independent on-chain confirmation of that claim.
Does anyone track whether Dusk's bridge operations are multisig by design, or is this a single-key setup?
@Dusk_Foundation $DUSK #dusk
On August 16, the Dusk team flagged suspicious activity on a team-managed wallet used for bridge operations, disabled the affected addresses, and paused bridge services while coordinating with Binance after part of the flow touched the exchange. What made me dig deeper: the team's own incident notice was explicit that this was a wallet-key issue, not a DuskDS protocol fault. That's a meaningful distinction architecturally the bridge sits as an operational layer on top of DuskDS's settlement, separate from the consensus and execution logic that DuskVM and DuskEVM actually run on.
Checking the sequence, the pause looks reactive rather than automated a monitoring alert triggered manual containment, not a circuit-breaker built into the protocol. That's worth noting for anyone assuming bridge security is enforced at the base-layer level here.
What I can't confirm: the exact number or value of transactions during the incident window, or whether the recycled addresses were multisig-controlled. Dusk's notice states no user funds were affected, but I haven't seen independent on-chain confirmation of that claim.
Does anyone track whether Dusk's bridge operations are multisig by design, or is this a single-key setup?
@Dusk_Foundation $DUSK #dusk