After a transaction fails, the DUSK missing from your wallet—does that mean it was all for nothing? 👻
When I looked through Dusk’s Tokenomics page, I noticed a rule that’s easy to miss: if a transaction runs out of gas, it will roll back, but the gas already consumed is not refunded. What people call “failure” on the user side can actually lead to at least two different outcomes on-chain.
Gas limit is the maximum amount of work this call can do. Gas price is the price per unit of work. Fees are calculated based on actual gas consumed—unused gas isn’t deducted. The rules themselves are fine; the trouble is that wallets typically only show a big red “Failed” in white text.
Back then, I probably blamed users for not providing enough fees. Looking back now, whether the product clearly explains the reason for failure directly determines whether users are willing to try again. If it’s due to insufficient workload, or instead something like permissions, parameters, or network conditions, the handling is completely different.
Let me give a scenario: someone uses a small amount of DUSK to call a contract but sets the gas limit too low. The transaction fails—the balance is reduced, but the on-chain state doesn’t change. They try again and pay another fee. If the root cause was a parameter mistake, the fee will keep getting burned.
So I really don’t think Dusk’s gas mechanism can be simply summarized as “you get charged even when it fails.” The protocol has already clearly defined the boundaries between what is refunded (unused gas) and what is charged (gas consumed before running out). What the product needs to do is translate those boundaries into plain language. @Dusk —if it could display gas limit, actual gas consumed, and the failure reason all together in the failure record, $DUSK ’s usage threshold would have one fewer layer of misunderstanding. #dusk
When I looked through Dusk’s Tokenomics page, I noticed a rule that’s easy to miss: if a transaction runs out of gas, it will roll back, but the gas already consumed is not refunded. What people call “failure” on the user side can actually lead to at least two different outcomes on-chain.
Gas limit is the maximum amount of work this call can do. Gas price is the price per unit of work. Fees are calculated based on actual gas consumed—unused gas isn’t deducted. The rules themselves are fine; the trouble is that wallets typically only show a big red “Failed” in white text.
Back then, I probably blamed users for not providing enough fees. Looking back now, whether the product clearly explains the reason for failure directly determines whether users are willing to try again. If it’s due to insufficient workload, or instead something like permissions, parameters, or network conditions, the handling is completely different.
Let me give a scenario: someone uses a small amount of DUSK to call a contract but sets the gas limit too low. The transaction fails—the balance is reduced, but the on-chain state doesn’t change. They try again and pay another fee. If the root cause was a parameter mistake, the fee will keep getting burned.
So I really don’t think Dusk’s gas mechanism can be simply summarized as “you get charged even when it fails.” The protocol has already clearly defined the boundaries between what is refunded (unused gas) and what is charged (gas consumed before running out). What the product needs to do is translate those boundaries into plain language. @Dusk —if it could display gas limit, actual gas consumed, and the failure reason all together in the failure record, $DUSK ’s usage threshold would have one fewer layer of misunderstanding. #dusk