Node returns “202 Accepted”—how many steps are left before real settlement is successful?
In traditional payment systems, “the bank has accepted” and “funds have arrived” are two different statuses. After studying the transaction lifecycle of @Dusk , I found that on-chain transactions also can’t be judged by only a single “success” message.
A typical Dusk L1 transaction goes through:
submission, node pre-validation, entry into the local mempool, propagation to other nodes, selection by the block producer, execution, and finally confirmation.
The easiest part to misunderstand is that the transaction submission API returning 202 Accepted only means the node has received the data and is preparing to propagate it—it does not mean it has entered a block.
Even if the transaction is in the node’s mempool, it only indicates it passed that node’s initial checks. After it enters a block, you still need to check whether the err field in the execution result is empty. If a contract rolls back due to parameter, state, or Gas issues, the Nonce and the already-consumed Gas may still be unrecoverable.
Finally, you must wait for the block to reach the finalized state. The official documentation explicitly warns that you cannot treat included, removed, or a regular accepted as a direct signal of payment finality.
This is crucial for Dusk’s future service securities settlement. What institutions care about is not whether the UI pops a green banner, but which irreversible state the asset delivery and accounting entries are based on.
Dusk’s website lists a network finality metric of about 10 seconds, but applications must still correctly identify final state rather than guessing the outcome by relying on a fixed 10-second wait.
I assess whether an institutional settlement system is mature by focusing on:
1. Stability of final confirmation time;
2. Execution failure rate;
3. Number of block rollbacks and re-reconciliations;
4. Whether the application distinguishes between submission, execution, and final confirmation;
5. Whether the asset side and payment side use the same finality standard.
Real on-chain settlement isn’t just that the transaction was sent—it’s that all parties involved have a consistent answer to “when it is okay to record the books.” #dusk $DUSK
In traditional payment systems, “the bank has accepted” and “funds have arrived” are two different statuses. After studying the transaction lifecycle of @Dusk , I found that on-chain transactions also can’t be judged by only a single “success” message.
A typical Dusk L1 transaction goes through:
submission, node pre-validation, entry into the local mempool, propagation to other nodes, selection by the block producer, execution, and finally confirmation.
The easiest part to misunderstand is that the transaction submission API returning 202 Accepted only means the node has received the data and is preparing to propagate it—it does not mean it has entered a block.
Even if the transaction is in the node’s mempool, it only indicates it passed that node’s initial checks. After it enters a block, you still need to check whether the err field in the execution result is empty. If a contract rolls back due to parameter, state, or Gas issues, the Nonce and the already-consumed Gas may still be unrecoverable.
Finally, you must wait for the block to reach the finalized state. The official documentation explicitly warns that you cannot treat included, removed, or a regular accepted as a direct signal of payment finality.
This is crucial for Dusk’s future service securities settlement. What institutions care about is not whether the UI pops a green banner, but which irreversible state the asset delivery and accounting entries are based on.
Dusk’s website lists a network finality metric of about 10 seconds, but applications must still correctly identify final state rather than guessing the outcome by relying on a fixed 10-second wait.
I assess whether an institutional settlement system is mature by focusing on:
1. Stability of final confirmation time;
2. Execution failure rate;
3. Number of block rollbacks and re-reconciliations;
4. Whether the application distinguishes between submission, execution, and final confirmation;
5. Whether the asset side and payment side use the same finality standard.
Real on-chain settlement isn’t just that the transaction was sent—it’s that all parties involved have a consistent answer to “when it is okay to record the books.” #dusk $DUSK