One of the most dangerous misunderstandings when refilling an exchange or using a payment system is treating a node’s returned “202 Accepted” as proof of funds arriving.
I’ve re-assembled the transaction lifecycle for @Dusk . After the transaction is submitted to the node, “202” only means the node has received the data and is preparing to forward it—it does not mean the transaction is already in the real mempool, nor that it has been packaged, executed successfully, or reached final confirmation.
A single Dusk L1 transaction must go through several stages: submission, pre-validation, entering the local mempool, network propagation, block selection, contract execution, and block finalization. Even if the transaction is already included in an accepted block, you still need to check whether the Error in the Executed event is empty; if a contract error occurs, the Nonce or Phoenix Notes may still be consumed, and Gas must be paid as well. Only when the block status becomes Finalized can you treat the transaction as an irreversible result.
This is like a shipping system showing “picked up.” It only proves the courier has received the parcel; it does not prove the parcel has been delivered to the recipient.
Therefore, if an exchange credits an account early based on the transaction hash, it may mistake a transaction that has been replaced, failed to execute, or has not yet been finalized as real deposits. What’s most worth monitoring next is how the wallet displays the transaction stage, what finality standard the exchange uses, and the proportion of executions that fail but still have Gas paid.
Receiving a transaction doesn’t mean executing it; executing a transaction doesn’t mean final settlement. What a financial system truly needs to confirm is the last step.#dusk $DUSK
I’ve re-assembled the transaction lifecycle for @Dusk . After the transaction is submitted to the node, “202” only means the node has received the data and is preparing to forward it—it does not mean the transaction is already in the real mempool, nor that it has been packaged, executed successfully, or reached final confirmation.
A single Dusk L1 transaction must go through several stages: submission, pre-validation, entering the local mempool, network propagation, block selection, contract execution, and block finalization. Even if the transaction is already included in an accepted block, you still need to check whether the Error in the Executed event is empty; if a contract error occurs, the Nonce or Phoenix Notes may still be consumed, and Gas must be paid as well. Only when the block status becomes Finalized can you treat the transaction as an irreversible result.
This is like a shipping system showing “picked up.” It only proves the courier has received the parcel; it does not prove the parcel has been delivered to the recipient.
Therefore, if an exchange credits an account early based on the transaction hash, it may mistake a transaction that has been replaced, failed to execute, or has not yet been finalized as real deposits. What’s most worth monitoring next is how the wallet displays the transaction stage, what finality standard the exchange uses, and the proportion of executions that fail but still have Gas paid.
Receiving a transaction doesn’t mean executing it; executing a transaction doesn’t mean final settlement. What a financial system truly needs to confirm is the last step.#dusk $DUSK