#dusk $DUSK Authorization has already been approved and sent out; the exchange didn’t go through, and staking also stopped. At this point, the funds didn’t follow the planned route, but the market is still moving. Next comes revoking the authorization, resending, and hedging—every step requires paying again.----When you see a trade flow designed like this, what do you think?
I’m looking at the common path “Approve → Swap → Stake” and comparing it with Dusk’s current transaction structure. In the open discussions in Dusk’s official Rusk repository, it’s noted that a single Moonlight or Phoenix transaction currently carries only one top-level action, and the transaction format doesn’t have a native Batch. There’s no dedicated routing contract—so the three steps have to be sent separately. Once the first step is confirmed, if the second step fails, the earlier step won’t automatically be rolled back.
When I saw that all three steps in this flow each charge Gas, I really did feel a bit happy for $DUSK . But once I mapped out the positions after failure and the remediation costs, that excitement vanished instantly. The thing that fully succeeds generates business fees; revoking authorization, retrying, and doing reverse operations generates “incident fees.” Both types of fees consume DUSK, but in the long run, the value is vastly different.
Dusk could let a routing contract handle the three steps first, but some target contracts only recognize “the person calling right now.” They would see the routing contract, and might not acknowledge the permissions of the real user. Native Batch at the protocol layer could preserve the user’s identity, but the trade format, nodes, and wallets would all need to be upgraded together. I suddenly feel like this problem is quite hard to solve.
Still, Phoenix has a Dusk-specific ace up its sleeve: privacy proofs only record the “fingerprint” of the call contents—there’s no need to understand every step inside. If Batch is added in the future, in theory Dusk wouldn’t need to redo the privacy circuits or the entire proof parameter set. That gives Dusk a chance to turn complex flows into “all succeed or all revert,” and the cost to modify the system may be lower as well.
For $DUSK , I think single-flow Gas should be evaluated in the same table as complete success rate, the share of remediation transactions, and user reusability. Charging for every button isn’t enough. Only when a whole set of transactions can be deployed with high efficiency and a great user experience will users be willing to keep leaving their next batch of funds on-chain.
A cheaper and smoother experience—what transaction would refuse that? That’s also one of the indicators I use to gauge $DUSK ’s long-term valuation.
@Dusk
$BTC
I’m looking at the common path “Approve → Swap → Stake” and comparing it with Dusk’s current transaction structure. In the open discussions in Dusk’s official Rusk repository, it’s noted that a single Moonlight or Phoenix transaction currently carries only one top-level action, and the transaction format doesn’t have a native Batch. There’s no dedicated routing contract—so the three steps have to be sent separately. Once the first step is confirmed, if the second step fails, the earlier step won’t automatically be rolled back.
When I saw that all three steps in this flow each charge Gas, I really did feel a bit happy for $DUSK . But once I mapped out the positions after failure and the remediation costs, that excitement vanished instantly. The thing that fully succeeds generates business fees; revoking authorization, retrying, and doing reverse operations generates “incident fees.” Both types of fees consume DUSK, but in the long run, the value is vastly different.
Dusk could let a routing contract handle the three steps first, but some target contracts only recognize “the person calling right now.” They would see the routing contract, and might not acknowledge the permissions of the real user. Native Batch at the protocol layer could preserve the user’s identity, but the trade format, nodes, and wallets would all need to be upgraded together. I suddenly feel like this problem is quite hard to solve.
Still, Phoenix has a Dusk-specific ace up its sleeve: privacy proofs only record the “fingerprint” of the call contents—there’s no need to understand every step inside. If Batch is added in the future, in theory Dusk wouldn’t need to redo the privacy circuits or the entire proof parameter set. That gives Dusk a chance to turn complex flows into “all succeed or all revert,” and the cost to modify the system may be lower as well.
For $DUSK , I think single-flow Gas should be evaluated in the same table as complete success rate, the share of remediation transactions, and user reusability. Charging for every button isn’t enough. Only when a whole set of transactions can be deployed with high efficiency and a great user experience will users be willing to keep leaving their next batch of funds on-chain.
A cheaper and smoother experience—what transaction would refuse that? That’s also one of the indicators I use to gauge $DUSK ’s long-term valuation.
@Dusk
$BTC