I get a strong feeling of continuity from using DUSK for gas on both sides of Dusk Network's architecture.
The live Dusk L1 and the testnet DuskEVM are still separate execution environments. DuskEVM sends transactions to a sequencer, publishes batches and state commitments to DuskDS, and relies on a bridge to move DUSK and messages between the two.
One asset does not mean one state.
That distinction is easy to miss in a wallet. A balance can leave the L1, appear inside DuskEVM, pay for a Solidity contract, and later return. To the user it looks like DUSK throughout. Underneath, each transition depends on a different stage and status.
This matters beyond token movement. Dusk wants EVM applications to connect with L1 assets and privacy-oriented workflows. If an application treats a bridge submission as completed L1 settlement, it can act on value before the cross-layer process has reached the state the user assumes.
The same ambiguity can affect messages. A contract call on one side may depend on state that the other side has not yet recognized.
I am not looking for identical timing across both environments. I am looking for explicit state.
The wallet should say whether funds are on the L1, accepted by the bridge, represented on DuskEVM, or available to return. Applications should consume protocol status instead of guessing from elapsed time. Failed and delayed transfers need one recovery path that does not create a second transaction by accident.
The best evidence would be repeated deposits and withdrawals under load, with public latency distributions and no ambiguous balances after interruptions.
Dusk can make the same token useful across its stack. The harder task is making every user know which system currently controls that token and what must happen before control moves again.
@Dusk_Foundation $DUSK #dusk
$ACE $BTW
The live Dusk L1 and the testnet DuskEVM are still separate execution environments. DuskEVM sends transactions to a sequencer, publishes batches and state commitments to DuskDS, and relies on a bridge to move DUSK and messages between the two.
One asset does not mean one state.
That distinction is easy to miss in a wallet. A balance can leave the L1, appear inside DuskEVM, pay for a Solidity contract, and later return. To the user it looks like DUSK throughout. Underneath, each transition depends on a different stage and status.
This matters beyond token movement. Dusk wants EVM applications to connect with L1 assets and privacy-oriented workflows. If an application treats a bridge submission as completed L1 settlement, it can act on value before the cross-layer process has reached the state the user assumes.
The same ambiguity can affect messages. A contract call on one side may depend on state that the other side has not yet recognized.
I am not looking for identical timing across both environments. I am looking for explicit state.
The wallet should say whether funds are on the L1, accepted by the bridge, represented on DuskEVM, or available to return. Applications should consume protocol status instead of guessing from elapsed time. Failed and delayed transfers need one recovery path that does not create a second transaction by accident.
The best evidence would be repeated deposits and withdrawals under load, with public latency distributions and no ambiguous balances after interruptions.
Dusk can make the same token useful across its stack. The harder task is making every user know which system currently controls that token and what must happen before control moves again.
@Dusk_Foundation $DUSK #dusk
$ACE $BTW