I went into the DuskEVM bridge guide looking for withdrawal timing.
The fee line was what made me stop.
Moving DUSK into the current DuskEVM testnet flow is fairly simple: submit the deposit on Dusk L1, then wait for the balance to appear on DuskEVM.
Coming back is different.
A withdrawal requires three separate actions:
Initiate it on DuskEVM.
Prove it on Dusk L1.
Finalize it on Dusk L1.
The wallet can move through “Waiting for output proposal,” “Ready to prove,” “Proof submitted” and “Waiting to finalize” before the DUSK is released.
That part makes sense. The return journey is where DuskDS verifies the state coming from the EVM layer.
But then I noticed the user also needs enough unshielded DUSK on the L1 to pay for both the proof and finalization transactions.
So someone can hold DUSK inside DuskEVM, start moving it back, and still need a separate usable L1 balance to complete the exit.
The funds are not necessarily stuck. The user may simply be missing the asset required to finish proving that they are allowed to retrieve them.
That feels like a small technical requirement until DuskEVM is used by someone who has never touched Dusk L1 directly.
A Solidity developer may understand contracts and MetaMask perfectly, while the end user only sees a withdrawal sitting at “Waiting to finalize.”
Dusk’s docs are careful here. They tell users to follow the wallet status rather than estimate readiness from elapsed time alone.
Now I am watching how much of this survives into the final production experience.
Will users still manually manage three transactions and two L1 fees, or will the wallet abstract the process without hiding which settlement stage their money has actually reached?
The bridge is not only moving DUSK between layers. It is where DuskEVM’s familiar front end meets Dusk-native settlement and where that difference becomes impossible to ignore.
@Dusk $DUSK #dusk
The fee line was what made me stop.
Moving DUSK into the current DuskEVM testnet flow is fairly simple: submit the deposit on Dusk L1, then wait for the balance to appear on DuskEVM.
Coming back is different.
A withdrawal requires three separate actions:
Initiate it on DuskEVM.
Prove it on Dusk L1.
Finalize it on Dusk L1.
The wallet can move through “Waiting for output proposal,” “Ready to prove,” “Proof submitted” and “Waiting to finalize” before the DUSK is released.
That part makes sense. The return journey is where DuskDS verifies the state coming from the EVM layer.
But then I noticed the user also needs enough unshielded DUSK on the L1 to pay for both the proof and finalization transactions.
So someone can hold DUSK inside DuskEVM, start moving it back, and still need a separate usable L1 balance to complete the exit.
The funds are not necessarily stuck. The user may simply be missing the asset required to finish proving that they are allowed to retrieve them.
That feels like a small technical requirement until DuskEVM is used by someone who has never touched Dusk L1 directly.
A Solidity developer may understand contracts and MetaMask perfectly, while the end user only sees a withdrawal sitting at “Waiting to finalize.”
Dusk’s docs are careful here. They tell users to follow the wallet status rather than estimate readiness from elapsed time alone.
Now I am watching how much of this survives into the final production experience.
Will users still manually manage three transactions and two L1 fees, or will the wallet abstract the process without hiding which settlement stage their money has actually reached?
The bridge is not only moving DUSK between layers. It is where DuskEVM’s familiar front end meets Dusk-native settlement and where that difference becomes impossible to ignore.
@Dusk $DUSK #dusk
