Citadel Explained: How Dusk Handles Identity and Selective Disclosure
Went digging into Dusk's bridge operations this week and hit something odd before I even got to Citadel itself: the "bridge incident" I kept seeing referenced doesn't have a consistent timestamp across sources. One aggregator dates the suspicious wallet activity to August 16, but Dusk's own news index lists a "Bridge Services Incident Notice" from January and a separate post-mortem in March no August entry visible. Same underlying story (team-managed bridge wallet flagged, addresses recycled, bridge paused, a Web Wallet recipient blocklist shipped to block transfers to flagged addresses), but the paper trail doesn't line up cleanly.
What the confirmed pieces show: bridge services were paused as a precaution, a small number of transactions moved during the flagged window, and part of that flow reportedly touched Binance before containment. That's a real operational response, not speculation.
What it doesn't show: a verified single date, or public wallet addresses I could trace myself. For a project whose core pitch is selective, verifiable disclosure, that's a mildly ironic gap.
Has anyone pulled the actual on-chain addresses tied to this, and can you confirm which week it happened?
That table lays out what's confirmed versus what I'm inferring the date mismatch itself is the most interesting data point here, since it's exactly the kind of thing Citadel's on-chain verification model is supposed to make unambiguous.
@Dusk $DUSK #dusk
Went digging into Dusk's bridge operations this week and hit something odd before I even got to Citadel itself: the "bridge incident" I kept seeing referenced doesn't have a consistent timestamp across sources. One aggregator dates the suspicious wallet activity to August 16, but Dusk's own news index lists a "Bridge Services Incident Notice" from January and a separate post-mortem in March no August entry visible. Same underlying story (team-managed bridge wallet flagged, addresses recycled, bridge paused, a Web Wallet recipient blocklist shipped to block transfers to flagged addresses), but the paper trail doesn't line up cleanly.
What the confirmed pieces show: bridge services were paused as a precaution, a small number of transactions moved during the flagged window, and part of that flow reportedly touched Binance before containment. That's a real operational response, not speculation.
What it doesn't show: a verified single date, or public wallet addresses I could trace myself. For a project whose core pitch is selective, verifiable disclosure, that's a mildly ironic gap.
Has anyone pulled the actual on-chain addresses tied to this, and can you confirm which week it happened?
That table lays out what's confirmed versus what I'm inferring the date mismatch itself is the most interesting data point here, since it's exactly the kind of thing Citadel's on-chain verification model is supposed to make unambiguous.
@Dusk $DUSK #dusk
