"EVM compatible"—those four words are overused in ETH L2 expansion narratives, but if you actually open OP Stack’s withdrawal flow, you’ll find you’re not doing cross-chain at all. You’re reconciling with a four-stage state machine: L2 initiates → wait until an output proposal covers that specific state → on L1 call prove_withdrawal to submit the Merkle proof → then complete the 7-day dispute-game window before finalizing. On Base/OP Mainnet, users have already complained about this accounting: between the first three steps, funds are locked in an L1 bridge contract—not lost, but definitely not yours. If any one step has insufficient L1 gas, an output root gets challenged, or the proposer stalls, withdrawals get stuck at "Ready to prove" or "Waiting for finalization".
On Arbitrum, the surface has only two items (an L1 retryable ticket + an L2 execution), but if the ticket’s automatic redeem fails, it drops into an in-memory buffer. Anyone can manually redeem within 7 days; after expiration it returns to escrow. Even more ominous is the out-of-order execution pointed out by Trail of Bits—if A runs before B completes and the protocol doesn’t handle such timing, it effectively buries a reentrancy-type vulnerability. This shows that "fewer steps" doesn’t mean "easier to understand state"—it just hides complexity inside precompiles.
So exiting #dusk EVM Testnet into three steps—initiate / submit proof / finalize—isn’t @Dusk intentionally making things difficult for users. It’s just that it didn’t secretly simplify OP’s whole "7-day challenge period + proof maturity" setup. Running on the testnet with test tokens can only demonstrate that the wallet recognizes these state enumerations: Waiting for output proposal / Ready to prove / Waiting to finalize. It can’t prove that on mainnet under high load, the proposer will reliably produce roots, that dispute games won’t be dragged into continuous challenges, or that users will have enough EVM-side gas and also enough for the two L1 actions.
I’ve never seen an ETH L2 bridge count "which toolchains are compatible." It only acknowledges three hard signals: whether the exit median time converges downward away from the 7-day theoretical value, whether a failed prove can switch to another output root without restarting the full process, and whether when assets are stuck, users can read the storage proof of their own withdrawal from an Etherscan contract. Fewer buttons are just UX sugar; state that can be explained is the real safety baseline. Until these three items are re-verified against mainnet data, "EVM compatible" is only developer convenience—not user readiness. So it’s true for $DUSK , it’s true for Base, and it’s also true for Arbitrum.
On Arbitrum, the surface has only two items (an L1 retryable ticket + an L2 execution), but if the ticket’s automatic redeem fails, it drops into an in-memory buffer. Anyone can manually redeem within 7 days; after expiration it returns to escrow. Even more ominous is the out-of-order execution pointed out by Trail of Bits—if A runs before B completes and the protocol doesn’t handle such timing, it effectively buries a reentrancy-type vulnerability. This shows that "fewer steps" doesn’t mean "easier to understand state"—it just hides complexity inside precompiles.
So exiting #dusk EVM Testnet into three steps—initiate / submit proof / finalize—isn’t @Dusk intentionally making things difficult for users. It’s just that it didn’t secretly simplify OP’s whole "7-day challenge period + proof maturity" setup. Running on the testnet with test tokens can only demonstrate that the wallet recognizes these state enumerations: Waiting for output proposal / Ready to prove / Waiting to finalize. It can’t prove that on mainnet under high load, the proposer will reliably produce roots, that dispute games won’t be dragged into continuous challenges, or that users will have enough EVM-side gas and also enough for the two L1 actions.
I’ve never seen an ETH L2 bridge count "which toolchains are compatible." It only acknowledges three hard signals: whether the exit median time converges downward away from the 7-day theoretical value, whether a failed prove can switch to another output root without restarting the full process, and whether when assets are stuck, users can read the storage proof of their own withdrawal from an Etherscan contract. Fewer buttons are just UX sugar; state that can be explained is the real safety baseline. Until these three items are re-verified against mainnet data, "EVM compatible" is only developer convenience—not user readiness. So it’s true for $DUSK , it’s true for Base, and it’s also true for Arbitrum.