A DUSK TRANSACTION CAN BE “ACCEPTED” BEFORE THE EXCHANGE SHOULD TREAT IT AS DONE.
I was reading through @Dusk_Foundation ’s transaction API and one status code ended up bothering me more than the usual finality discussion:
202 Accepted.
When a Dusk node returns 202 after a transaction is propagated, it means the transaction has been accepted for routing.
It does not yet prove that it entered the real mempool, reached peers, executed successfully or became final.
That sounds like a small API detail.
For an exchange processing withdrawals, I don’t think it is.
I had been mentally treating withdrawal processing as something close to:
send transaction → network accepts it → wait for finality → close withdrawal.
But there is an awkward state in the middle where the exchange has sent something and still does not have enough information to safely call the economic action complete.
That changes the problem.
Transaction submission is not transaction completion.
And retrying a failed API request is not necessarily the same thing as deciding that the original withdrawal never existed.
Dusk’s documentation even warns that a signing service needs to serialize nonce allocation, retain submitted transactions and check pending and committed account state before reusing a nonce.
This is the part I find interesting.
Deterministic finality can make the end of a transaction very clear.
It cannot automatically make every state before finality equally easy for an exchange to handle.
So if I were evaluating a serious Dusk integration, I wouldn’t only measure settlement speed.
I’d want to know what happens during node failures, timeouts and ambiguous submissions:
How many withdrawals can recover automatically without creating duplicate instructions or requiring someone to manually decide what happened?
The best transaction infrastructure may be the one where the failure path becomes boring.
That seems much harder than making the happy path fast.
#dusk $DUSK @Dusk
$GPS $TUT
I was reading through @Dusk_Foundation ’s transaction API and one status code ended up bothering me more than the usual finality discussion:
202 Accepted.
When a Dusk node returns 202 after a transaction is propagated, it means the transaction has been accepted for routing.
It does not yet prove that it entered the real mempool, reached peers, executed successfully or became final.
That sounds like a small API detail.
For an exchange processing withdrawals, I don’t think it is.
I had been mentally treating withdrawal processing as something close to:
send transaction → network accepts it → wait for finality → close withdrawal.
But there is an awkward state in the middle where the exchange has sent something and still does not have enough information to safely call the economic action complete.
That changes the problem.
Transaction submission is not transaction completion.
And retrying a failed API request is not necessarily the same thing as deciding that the original withdrawal never existed.
Dusk’s documentation even warns that a signing service needs to serialize nonce allocation, retain submitted transactions and check pending and committed account state before reusing a nonce.
This is the part I find interesting.
Deterministic finality can make the end of a transaction very clear.
It cannot automatically make every state before finality equally easy for an exchange to handle.
So if I were evaluating a serious Dusk integration, I wouldn’t only measure settlement speed.
I’d want to know what happens during node failures, timeouts and ambiguous submissions:
How many withdrawals can recover automatically without creating duplicate instructions or requiring someone to manually decide what happened?
The best transaction infrastructure may be the one where the failure path becomes boring.
That seems much harder than making the happy path fast.
#dusk $DUSK @Dusk
$GPS $TUT