docs.dusk.network's own core components page mentions "native bridging" as part of duskds, connecting duskevm and duskvm to the base layer. that's the third thing i've now found called a "bridge" in dusk's stack. i went and actually confirmed whether that's the same mechanism that got hit in january — and honestly i almost assumed it was, given how loosely "bridge" gets used everywhere — but it's not. dusk's own multilayer architecture post describes this one specifically as "validator-run, native and trustless, no external custodians or wrapped assets required," while the incident notice from january ties directly back to the old bep20 bridge address, a completely different, custodial-style mechanism for moving wrapped dusk to bsc.
so that's three separate bridges confirmed: the internal duskds-to-duskevm native bridge, the external bep20/bsc bridge that got hit, and the chainlink cct pathway for eth-solana. all real, all distinct, all sharing the word "bridge" with nothing distinguishing them by name anywhere i've found.
i don't think that's dusk being deceptive, modular architectures genuinely need multiple bridging layers for different jobs. i just think "dusk's bridge had an incident" is doing a lot of unearned precision for a sentence that could mean three different things depending on which one you mean.
does dusk have a single page anywhere that names and distinguishes all three by name in one place? 🧐
#dusk $DUSK @Dusk