#dusk $DUSK

I thought a fast DuskEVM transaction was basically a settled transaction.

Then I found a warning in Dusk’s docs that made me rethink that assumption.

DuskEVM separates transaction inclusion from settlement.

A transaction can be included in an L2 block quickly, but that doesn’t mean the resulting state has already settled back to the Dusk L1. The two stages are connected through batching, state commitments and fault proofs.


The detail I found most interesting is that @Dusk_Foundation explicitly tells applications moving value between DuskEVM and the Dusk L1 NOT to infer finality simply from elapsed time.

That sounds obvious after reading it, but it’s actually an important design distinction.

“Confirmed quickly” and “safe to treat as settled” are not necessarily the same thing.

For an application moving real value, using a timer as a shortcut could mean acting on inclusion while the cross-layer settlement process is still incomplete.

So I’m left with one question:

What exact protocol status should an application treat as authoritative before releasing value across the DuskEVM ↔ Dusk L1 boundary?