#dusk $DUSK @Dusk The transaction shows “success”—does that really mean it’s done?
Last night, while going through Dusk’s development documentation, I noticed a detail I hadn’t paid much attention to before.
After a transaction is submitted, the node returns 202 Accepted—which only means the request has been received and is being processed, not that the transaction has already completed.
Keep reading and you’ll find that it still has to go through admission, the mempool, block selection, and execution.
Even if it’s already executed, it isn’t over yet.
Because even a block that has been accepted can still be rolled back.
Only when the block enters the finalized state does the transaction truly gain finality.
I find this detail quite interesting.
When we usually say “transaction success,” we’re actually mixing several completely different states together:
The node has received it, and the network has accepted it—those are not the same;
Entering a block, and executing successfully—those are not the same either;
Execution success doesn’t automatically mean final settlement.
For ordinary transfers, this may just be a matter of a few state distinctions.
But what if, in the future, the chain is running securities, payments, or other financial assets?
Then “almost successful” clearly isn’t enough.
What needs answering instead is:
At which specific state does the transfer of rights and obligations for the asset truly take effect?
This is also one way I’ve recently come to better understand Dusk’s “deterministic settlement.”
What it really needs to solve may never have been just making transactions faster, but making participants clearly know:
When they can stop waiting, and when they can truly treat the transaction as already completed.
That might be the real meaning of the words “transaction completed” in financial infrastructure.
@Dusk $DUSK #DUSK
Last night, while going through Dusk’s development documentation, I noticed a detail I hadn’t paid much attention to before.
After a transaction is submitted, the node returns 202 Accepted—which only means the request has been received and is being processed, not that the transaction has already completed.
Keep reading and you’ll find that it still has to go through admission, the mempool, block selection, and execution.
Even if it’s already executed, it isn’t over yet.
Because even a block that has been accepted can still be rolled back.
Only when the block enters the finalized state does the transaction truly gain finality.
I find this detail quite interesting.
When we usually say “transaction success,” we’re actually mixing several completely different states together:
The node has received it, and the network has accepted it—those are not the same;
Entering a block, and executing successfully—those are not the same either;
Execution success doesn’t automatically mean final settlement.
For ordinary transfers, this may just be a matter of a few state distinctions.
But what if, in the future, the chain is running securities, payments, or other financial assets?
Then “almost successful” clearly isn’t enough.
What needs answering instead is:
At which specific state does the transfer of rights and obligations for the asset truly take effect?
This is also one way I’ve recently come to better understand Dusk’s “deterministic settlement.”
What it really needs to solve may never have been just making transactions faster, but making participants clearly know:
When they can stop waiting, and when they can truly treat the transaction as already completed.
That might be the real meaning of the words “transaction completed” in financial infrastructure.
@Dusk $DUSK #DUSK
