I expected one transaction. I counted three.
That's a DuskEVM bridge withdrawal, straight from Dusk's own guide:
1. Initiate the withdrawal on DuskEVM
2. Prove it on the Dusk L1
3. Finalize it on the Dusk L1
Three on-chain actions, and fees on both sides: the source transaction, then two more on L1.
The instruction I respect most is the one about timing. The docs say withdrawal readiness depends on published network state, proof maturity and dispute-game checks, and that the wallet's status field is authoritative — do not infer readiness from elapsed time. That line exists because rollup withdrawal windows are not clocks, they are state machines. Every integration that hardcoded "wait N minutes, then finalize" eventually breaks: a proposal lands late, a check runs long, and your finalizer submits into a state that isn't ready.
The second detail says more than the step count. The guide tells you to keep enough unshielded DUSK on the L1 to pay for both the proof and the finalization transaction. Sit with that on a chain whose core pitch is confidential transfers: the exit path from its own EVM layer is denominated in transparent balance. Caveat, and it matters — this is the testnet guide, DuskEVM is still labelled Testnet, so the mainnet shape could change.
To be fair, none of this is a Dusk invention. It is standard optimistic-rollup design inherited from the OP Stack, and every OP chain asks the same three actions of you. So the question isn't whether Dusk got something wrong. It's what standard rollup UX does to a chain whose entire differentiator is privacy.
Do privacy-first chains need a fundamentally different bridge design? Or is transparent gas at the settlement layer a fair price to pay for a familiar developer stack?
#dusk $DUSK @Dusk
That's a DuskEVM bridge withdrawal, straight from Dusk's own guide:
1. Initiate the withdrawal on DuskEVM
2. Prove it on the Dusk L1
3. Finalize it on the Dusk L1
Three on-chain actions, and fees on both sides: the source transaction, then two more on L1.
The instruction I respect most is the one about timing. The docs say withdrawal readiness depends on published network state, proof maturity and dispute-game checks, and that the wallet's status field is authoritative — do not infer readiness from elapsed time. That line exists because rollup withdrawal windows are not clocks, they are state machines. Every integration that hardcoded "wait N minutes, then finalize" eventually breaks: a proposal lands late, a check runs long, and your finalizer submits into a state that isn't ready.
The second detail says more than the step count. The guide tells you to keep enough unshielded DUSK on the L1 to pay for both the proof and the finalization transaction. Sit with that on a chain whose core pitch is confidential transfers: the exit path from its own EVM layer is denominated in transparent balance. Caveat, and it matters — this is the testnet guide, DuskEVM is still labelled Testnet, so the mainnet shape could change.
To be fair, none of this is a Dusk invention. It is standard optimistic-rollup design inherited from the OP Stack, and every OP chain asks the same three actions of you. So the question isn't whether Dusk got something wrong. It's what standard rollup UX does to a chain whose entire differentiator is privacy.
Do privacy-first chains need a fundamentally different bridge design? Or is transparent gas at the settlement layer a fair price to pay for a familiar developer stack?
#dusk $DUSK @Dusk
