#dusk $DUSK @Dusk
Honestly, I always thought “final” was one of those words that didnt need much expleining.
Either a transaction was final or it wasn't.
Then I looked closer at how @Dusk describes finality and found four stages: Accepted, Confirmed, Stable and Final.
It may sounds like four different ways of saying the same thing, but it ain't. In @Dusk mechanisam:

accepted means the block made it through the current consensus round;

confirmed means later blocks are building on it;

stable means enough history has accumulated that reversing it becomes increasingly unlikely;

Only Final gives you deterministic finality;

👉 And Im ngl - this is where it got interesting for me.

Dusk's rolling finality doesn't always take the same number of blocks. The path depends partly on what happaned in previous consensus iterations. A clean consensus run can reach finality diffrently from one where earlier candidates failed to attest.
So the guarantee itself is determinstic, but the path to that guarantee is not necessarily fixed.
So that's a gap worth naming directly: Dusk is built around fast, deterministic finality for regulated markets, but the mechanism getting you there is a variable, history dependent process , not a fixed clock.
That feels specially important for regulated assets.
Simply:
If you buy a share, the network might say:
“Yes, we processed this transaction.”
But that doesn't necessarily mean:
“This share is now permanently yours and nobody can reverse the transaction.”

Dusk seems to be drawing that line very deliberately.

This made me ask myself another question: when you're building financial infrastructure, is predictable finality more important than predictable time to finality?
$ZEC $ZEN