One thing that annoys me about crypto UX is the moment a transaction goes wrong.
You send it.
Something happens.
And then the wallet gives you a red error message that basically says:
“Good luck.”
I've had enough of those.
So when I was reading Dusk's transaction docs, I stopped at something that isn't particularly exciting, but probably should be.
Dusk separates the different things that can happen to a transaction.
A transaction can execute successfully.
It can fail.
A block containing it can later be reverted.
And applications are expected to listen for the relevant events and react accordingly rather than assuming that “I submitted it” means “it's done.”
That last part sounds obvious.
It isn't.
A wallet can tell you that a transaction was submitted, but that doesn't necessarily tell you what happened to the execution.
Dusk's docs even recommend that integrators monitor the transaction-executed event, check for errors, confirm the block is finalized, and handle a block revert by listening for the transaction events again.
I like that approach.
Not because it's revolutionary.
Actually, quite the opposite.
It feels like someone sat down and asked:
“What information does an application actually need when money is moving?”
That's a much better question than simply making the transaction system more complicated.
I don't know how much of this users will ever see directly.
Hopefully, not much.
If the infrastructure is doing its job, the wallet should turn all of this into something simple enough that I don't have to think about it.
But underneath that simple button, there needs to be a system that knows the difference between:
“I sent it.”
“It executed.”
“It finalized.”
and
“Something went wrong.”
That distinction is boring.
I think that's exactly why it's worth noticing.
#dusk $DUSK @Dusk
You send it.
Something happens.
And then the wallet gives you a red error message that basically says:
“Good luck.”
I've had enough of those.
So when I was reading Dusk's transaction docs, I stopped at something that isn't particularly exciting, but probably should be.
Dusk separates the different things that can happen to a transaction.
A transaction can execute successfully.
It can fail.
A block containing it can later be reverted.
And applications are expected to listen for the relevant events and react accordingly rather than assuming that “I submitted it” means “it's done.”
That last part sounds obvious.
It isn't.
A wallet can tell you that a transaction was submitted, but that doesn't necessarily tell you what happened to the execution.
Dusk's docs even recommend that integrators monitor the transaction-executed event, check for errors, confirm the block is finalized, and handle a block revert by listening for the transaction events again.
I like that approach.
Not because it's revolutionary.
Actually, quite the opposite.
It feels like someone sat down and asked:
“What information does an application actually need when money is moving?”
That's a much better question than simply making the transaction system more complicated.
I don't know how much of this users will ever see directly.
Hopefully, not much.
If the infrastructure is doing its job, the wallet should turn all of this into something simple enough that I don't have to think about it.
But underneath that simple button, there needs to be a system that knows the difference between:
“I sent it.”
“It executed.”
“It finalized.”
and
“Something went wrong.”
That distinction is boring.
I think that's exactly why it's worth noticing.
#dusk $DUSK @Dusk
