When you’re building an app that submits transactions to Dusk L1, getting a successful response from the node looks like the obvious moment to tell the user the action worked.

I caught myself reading it that way until I followed Dusk’s transaction lifecycle more carefully. A `202 Accepted` from the propagation endpoint only means the node accepted the transaction for routing. It does not mean the transaction reached a block, executed successfully or became final.

That turns what looks like a simple “send transaction” integration into something closer to state tracking. Once a transaction executes, Dusk exposes an `err` field, where `null` means the execution succeeded. Even then, an accepted block can still be reverted. Finality arrives when the block reaches the `finalized` state.

I think that reclassifies the builder’s job in a useful way.

You are not just wiring a button to an endpoint and waiting for HTTP success. You are deciding which network state your application is actually willing to translate into “complete” for the person using it.

Submitted is one state.

Executed successfully is another.

Final is the one that closes the loop.

@Dusk $DUSK #dusk