#dusk $DUSK @Dusk
I had to read this twice because an HTTP 202 Accepted normally makes my brain relax.
On Dusk, it probably shouldn’t.
When /transactions/propagate returns 202 Accepted, the node has accepted the transaction for routing.
That alone doesn’t prove the transaction:
entered the real mempool,
reached peers,
executed successfully,
or finalized.
At first this felt like an overly technical distinction.
Then I found the stranger edge case.
A valid transaction with a future nonce can wait in a prequeue until the missing nonce gap is resolved.
So you can receive a perfectly clean API response while the transaction still isn’t at the stage you probably care about.
That part bothered me.
A lot of infrastructure is built around a very human shortcut:
API said yes → job done.
Dusk’s exchange integration guidance makes the opposite assumption.
A withdrawal shouldn’t be treated as complete just because the propagation endpoint returned 202 Accepted. Execution and finality still need to be checked.
And if the transport layer times out, the safer recovery path is to rebroadcast the same signed transaction, not blindly create another one.
That’s where this stops being an HTTP-status-code curiosity.
If an exchange or wallet confuses transport acceptance with ledger completion, a tiny integration shortcut can become an accounting problem.
Maybe I’m overthinking a boring API response at night.
But I think the useful distinction is simple:
Transport success is not ledger success.
The API can say yes before the chain does.
I had to read this twice because an HTTP 202 Accepted normally makes my brain relax.
On Dusk, it probably shouldn’t.
When /transactions/propagate returns 202 Accepted, the node has accepted the transaction for routing.
That alone doesn’t prove the transaction:
entered the real mempool,
reached peers,
executed successfully,
or finalized.
At first this felt like an overly technical distinction.
Then I found the stranger edge case.
A valid transaction with a future nonce can wait in a prequeue until the missing nonce gap is resolved.
So you can receive a perfectly clean API response while the transaction still isn’t at the stage you probably care about.
That part bothered me.
A lot of infrastructure is built around a very human shortcut:
API said yes → job done.
Dusk’s exchange integration guidance makes the opposite assumption.
A withdrawal shouldn’t be treated as complete just because the propagation endpoint returned 202 Accepted. Execution and finality still need to be checked.
And if the transport layer times out, the safer recovery path is to rebroadcast the same signed transaction, not blindly create another one.
That’s where this stops being an HTTP-status-code curiosity.
If an exchange or wallet confuses transport acceptance with ledger completion, a tiny integration shortcut can become an accounting problem.
Maybe I’m overthinking a boring API response at night.
But I think the useful distinction is simple:
Transport success is not ledger success.
The API can say yes before the chain does.
