I almost gave up refreshing my balance twice before I understood what I was actually waiting on.
Dusk doesn't treat a bridged transaction as one single moment. A transaction gets included in an L2 block by the sequencer first, then the batcher publishes that data back to DuskDS, and only once state commitments and fault proofs anchor it there does the transfer actually settle.
Here's the part that changed my read on it: most EVM rollups make you sit through a roughly seven-day challenge window before a withdrawal is truly final, because someone has to have time to dispute a bad state. DuskEVM settles straight to DuskDS instead, no seven-day fault window. So the gap between inclusion and settlement isn't days, it's something you could blink through. That's a real design choice, not just plumbing.
Which almost makes it worse in a way. If the delay were long, you'd expect to wait and plan around it. Because it's fast, it's easy to mistake "included" for "final" and never notice there were two separate claims being made.
I like that the protocol still keeps those claims distinct even when the gap between them is small enough to ignore.
So is collapsing the fault window down to near-instant a genuine resilience upgrade over the standard rollup model, or does removing the long wait just remove the cue that told people to be careful?
#dusk @Dusk $DUSK $PENGU $TUT
Dusk doesn't treat a bridged transaction as one single moment. A transaction gets included in an L2 block by the sequencer first, then the batcher publishes that data back to DuskDS, and only once state commitments and fault proofs anchor it there does the transfer actually settle.
Here's the part that changed my read on it: most EVM rollups make you sit through a roughly seven-day challenge window before a withdrawal is truly final, because someone has to have time to dispute a bad state. DuskEVM settles straight to DuskDS instead, no seven-day fault window. So the gap between inclusion and settlement isn't days, it's something you could blink through. That's a real design choice, not just plumbing.
Which almost makes it worse in a way. If the delay were long, you'd expect to wait and plan around it. Because it's fast, it's easy to mistake "included" for "final" and never notice there were two separate claims being made.
I like that the protocol still keeps those claims distinct even when the gap between them is small enough to ignore.
So is collapsing the fault window down to near-instant a genuine resilience upgrade over the standard rollup model, or does removing the long wait just remove the cue that told people to be careful?
#dusk @Dusk $DUSK $PENGU $TUT
