#dusk $DUSK
I went back through the @Dusk documentation last night., I caught myself treating “finalized” as a single moment. I assumed that once a Dusk transaction was final, funds should immediately exist on DuskEVM. The docs made that assumption too simple.
On DuskEVM Testnet, a deposit is submitted and finalized on Dusk L1, then processed before the balance becomes available on DuskEVM. A withdrawal has more stages: initiate on DuskEVM, wait for an output, prove on Dusk L1, pass the required maturity and dispute-game checks, then finalize on L1. The documentation warns that inclusion, execution, and finality are not the same status, and readiness should come from protocol state rather than elapsed time.
That made me look at it differently.
My interpretation: the bridge is not a hiding delay; it is trying to turn a cross-layer state machine into something a wallet can explain. The tension is security versus operational dependence. Safer retries, rollback recovery, and challenge checks reduce one class of failure, but recovery paths also concentrate responsibility somewhere.
My uncertainty: during a rollback plus relayer failure, what can a user verify independently before funds are released or retried? Who can pause or resume bridge operations, and what limits that authority if the emergency lasts longer than expected?
I want to watch this in practice.
I went back through the @Dusk documentation last night., I caught myself treating “finalized” as a single moment. I assumed that once a Dusk transaction was final, funds should immediately exist on DuskEVM. The docs made that assumption too simple.
On DuskEVM Testnet, a deposit is submitted and finalized on Dusk L1, then processed before the balance becomes available on DuskEVM. A withdrawal has more stages: initiate on DuskEVM, wait for an output, prove on Dusk L1, pass the required maturity and dispute-game checks, then finalize on L1. The documentation warns that inclusion, execution, and finality are not the same status, and readiness should come from protocol state rather than elapsed time.
That made me look at it differently.
My interpretation: the bridge is not a hiding delay; it is trying to turn a cross-layer state machine into something a wallet can explain. The tension is security versus operational dependence. Safer retries, rollback recovery, and challenge checks reduce one class of failure, but recovery paths also concentrate responsibility somewhere.
My uncertainty: during a rollback plus relayer failure, what can a user verify independently before funds are released or retried? Who can pause or resume bridge operations, and what limits that authority if the emergency lasts longer than expected?
I want to watch this in practice.
