went back into dusk’s own docs today specifically to check something after writing about their bridge hack last week, and found a detail that connects to it directly.
dusk runs two transaction models on the same ledger. moonlight is public — normal, transparent, like most chains. phoenix is shielded — private, zk-based. switching between them, shield to unshield or back, is a single atomic transaction handled by dusk’s own transfer contract.
no bridge. no wrapped token. per their own docs: “handled by the transfer contract in a single atomic transaction — no bridges, no wrapped tokens.”
that phrase stopped me, because january’s hack — the one that actually happened — went through exactly the thing this mechanism is built to avoid. a separate bridge, to an external chain, with a compromised signing wallet as the point of failure.
so the part of dusk that already got hit relied on bridging. the part converting between public and private modes internally, deliberately, does not.
i want to read that as “they learned the lesson before they needed to.” but i can’t actually confirm the internal shield/unshield mechanism is safer, only that it’s architecturally different — no external bridge doesn’t automatically mean no attack surface, just a different one. atomic same-ledger conversion between two totally different transaction models is still complex code that’s never been tested by a real attacker the way the bridge already has.
one part of dusk has a known failure mode now. the other part just hasn’t been attacked yet. those aren’t the same thing as safe, even if the design looks more careful.
#dusk @Dusk $DUSK
dusk runs two transaction models on the same ledger. moonlight is public — normal, transparent, like most chains. phoenix is shielded — private, zk-based. switching between them, shield to unshield or back, is a single atomic transaction handled by dusk’s own transfer contract.
no bridge. no wrapped token. per their own docs: “handled by the transfer contract in a single atomic transaction — no bridges, no wrapped tokens.”
that phrase stopped me, because january’s hack — the one that actually happened — went through exactly the thing this mechanism is built to avoid. a separate bridge, to an external chain, with a compromised signing wallet as the point of failure.
so the part of dusk that already got hit relied on bridging. the part converting between public and private modes internally, deliberately, does not.
i want to read that as “they learned the lesson before they needed to.” but i can’t actually confirm the internal shield/unshield mechanism is safer, only that it’s architecturally different — no external bridge doesn’t automatically mean no attack surface, just a different one. atomic same-ledger conversion between two totally different transaction models is still complex code that’s never been tested by a real attacker the way the bridge already has.
one part of dusk has a known failure mode now. the other part just hasn’t been attacked yet. those aren’t the same thing as safe, even if the design looks more careful.
#dusk @Dusk $DUSK
