I assumed that if I wanted to do three things on-chain, approve, swap, then stake, the chain would treat that as one thing happening or not happening at all. An open issue in Dusk's own Rusk repository says that's not how it works today.
A Dusk transaction today carries a single optional operation: one contract call, one deploy, or one memo, with one value, one recipient, one nonce, one signature. So approve, swap, and stake become three separate transactions, each independently included or dropped. Dusk's issue states it plainly: there is no atomicity guarantee across them. Land approve and swap but not stake, and you're left mid-flow with no protocol-level rollback.
The problem isn't only that multi-step flows can stop halfway. Fixing that changes who has to absorb the compatibility cost.
A batcher contract makes the whole sequence atomic, because a failed sub-call reverts the outer transaction. But a target contract checking who's calling it directly would see the batcher, not you, unless that contract is already written to look past the immediate caller. A protocol-level batch transaction keeps you as the caller at every step, but it doesn't ship without a new transaction format, consensus changes, a hard-fork, and every wallet SDK catching up.
Adding batching doesn't remove the tradeoff. It decides whether the compatibility burden sits in application authorization or in the protocol stack.
"Fixing atomicity doesn't remove the tradeoff; it decides where the compatibility burden and trust boundary move."
What I'd actually want to watch: whether Dusk chooses the application-level batcher or the protocol-level transaction, and what existing authorization assumptions that choice forces developers to change.
#dusk $DUSK @Dusk
A Dusk transaction today carries a single optional operation: one contract call, one deploy, or one memo, with one value, one recipient, one nonce, one signature. So approve, swap, and stake become three separate transactions, each independently included or dropped. Dusk's issue states it plainly: there is no atomicity guarantee across them. Land approve and swap but not stake, and you're left mid-flow with no protocol-level rollback.
The problem isn't only that multi-step flows can stop halfway. Fixing that changes who has to absorb the compatibility cost.
A batcher contract makes the whole sequence atomic, because a failed sub-call reverts the outer transaction. But a target contract checking who's calling it directly would see the batcher, not you, unless that contract is already written to look past the immediate caller. A protocol-level batch transaction keeps you as the caller at every step, but it doesn't ship without a new transaction format, consensus changes, a hard-fork, and every wallet SDK catching up.
Adding batching doesn't remove the tradeoff. It decides whether the compatibility burden sits in application authorization or in the protocol stack.
"Fixing atomicity doesn't remove the tradeoff; it decides where the compatibility burden and trust boundary move."
What I'd actually want to watch: whether Dusk chooses the application-level batcher or the protocol-level transaction, and what existing authorization assumptions that choice forces developers to change.
#dusk $DUSK @Dusk
