I used to think block confirmations were simple: transactions go into a block, then you count a few more blocks afterward, and basically you can treat it as safe. But tonight, when I was reading the transaction lifecycle documentation for @Dusk , one sentence stopped me: "accepted blocks can still be reverted." If they’ve already been accepted, why can they still be rolled back?
I only understood after reading the 2024 Whitepaper. A Dusk consensus round goes through multiple iterations, and the same round can produce competing blocks. Even if a higher-iteration block has already been accepted, as long as a lower-iteration competing block meets the conditions, a fallback can still be triggered.
Rolling Finality is even more counterintuitive. The whitepaper uses n to represent the number of iterations ahead whose attestation certainty is not yet completed. An accepted block must wait for 2×n consecutive attested or confirmed successor blocks to enter the confirmed state. If n=3, you need to observe the next 6 blocks that meet the conditions.
Only then did I realize that “confirmation count” isn’t a single universal measuring stick. Even if something is already on-chain, different consensus histories can have different levels of stability.
The advice in the current Docs is even more direct: don’t treat included, accepted, or even confirmed as a delivery signal—wait for something that is truly finalized.
For small transfers, it might just be a matter of seconds. But in large OTC or RWA DvP settlement, “seeing the transaction” and “irreversible settlement” are completely different things. Going forward, when looking at large Dusk transactions, just ask: has it been finalized?
#dusk $DUSK @Dusk
I only understood after reading the 2024 Whitepaper. A Dusk consensus round goes through multiple iterations, and the same round can produce competing blocks. Even if a higher-iteration block has already been accepted, as long as a lower-iteration competing block meets the conditions, a fallback can still be triggered.
Rolling Finality is even more counterintuitive. The whitepaper uses n to represent the number of iterations ahead whose attestation certainty is not yet completed. An accepted block must wait for 2×n consecutive attested or confirmed successor blocks to enter the confirmed state. If n=3, you need to observe the next 6 blocks that meet the conditions.
Only then did I realize that “confirmation count” isn’t a single universal measuring stick. Even if something is already on-chain, different consensus histories can have different levels of stability.
The advice in the current Docs is even more direct: don’t treat included, accepted, or even confirmed as a delivery signal—wait for something that is truly finalized.
For small transfers, it might just be a matter of seconds. But in large OTC or RWA DvP settlement, “seeing the transaction” and “irreversible settlement” are completely different things. Going forward, when looking at large Dusk transactions, just ask: has it been finalized?
#dusk $DUSK @Dusk
