Superbridge is your entrypoint into the Optimism Superchain. With the Superbridge you can bridge ETH and other assets like USDC back and forth between your favourite chains, with absolute peace of mind that your funds are secure.
One of the coolest features we’ve built into the Superbridge is the ability to force asset withdrawal from rollups. Forced withdrawals act as an escape hatch for users and allows them to exit rollups without needing to trust rollup operators to include their transactions. As we’ll explain in this post the feature is currently a bit of an intellectual nicety, but will become increasingly important as the number of OP rollups explodes.
Before we jump into forced withdrawals it’s important to understand how withdrawals work in the context of OP rollups, then we can look at deposit transactions and how they’re special, before combining them together for forced withdrawals.
Something we recognised early on while developing the Superbridge is that it’s clear OP rollups still have their training wheels on. Sequencer operation is done by a single and permissioned entity, core bridge contracts can be paused at will, contract upgrades aren’t currently subject to any timelocks and fault proofs for challenging the validity of state roots posted to Ethereum haven’t been implemented yet. As with everything in web3, we’re still early, and so despite these drawbacks (drawbacks that various teams are working very hard to address) the Superchain is flourishing even in the depths of this bear market.
A withdrawal operation in the context of an OP rollup refers to any transaction initiated on the rollup and completed on the L1. The most obvious use case for withdrawals is obviously token bridging, where tokens are locked/burned on the rollup and released/minted on the L1, but actually any valid transaction can be submitted as a withdrawal via the
However, the user experience around withdrawals is a little rough - it’s not the case that after initiating a transaction on the L2 that the action happens on the L1 immediately. First, the state root of the of the epoch containing your transaction needs to be proposed to the L1. Most mainnet deployments of OP rollups have a submission period of every 1800 blocks, or roughly every hour.
After this state root has been proposed, proof needs to be submitted that your transaction is present in the state the root represents. This is done via the
OptimismPortal contract, and a merkle trie is used to validate that the withdrawal hash you are proving exists in the proposed state root.
After proof has been submitted and accepted, the withdrawal enters its 7 day challenge period. Witnesses are able to challenge the integrity of submitted state roots and have the ability to discard state roots that are invalid.
It’s important to note that the 7 day challenge period applies to both the withdrawal and the state root proposal separately. So if you’re looking for the withdrawal to take as little time as possible it’s important to do the prove operation as soon as possible.
Finally, after the 7 day challenge period is over the withdrawal can be finalised (executed) via a final call to the
For a more comprehensive guide on withdrawals, please refer to the Optimism specs document on withdrawals.
A deposit operation in the OP Stack actually refers to any transaction initiated on the L1 and completed on the rollup. For our purposes, deposits are lot simpler to explain than withdrawals but many of the same properties hold. As with withdrawals, deposits aren’t solely used for bridging assets, any transaction can be submitted as a deposit transaction. That means you could submit a transaction on the L1 that simply transfers some of your ETH on the rollup to your buddy. You might not want to, because of the L1 gas costs involved, but doing this is censorship resistant and ensures your transaction will land - the key to understanding why forced withdrawals are useful.
Deposit transactions are initiated by calling
depositTransaction function on the L1
OptimismPortal contract. They emit a
TransactionDeposited event encoding the L2 transaction data which rollup nodes are constantly listening for. Once rollup nodes find these events they queue them up to be executed first thing in the new L2 block. And here comes the magic - if the sequencer doesn’t include one of these deposit transactions, which can be checked by anyone running their own rollup nodes, their bond can be slashed and forfeited to the watchful witness. This core premise that L1 initiated deposit transactions need to be included in the L2 is what allows users to transact, if they wish, with the same level of censorship resistance they would find on Ethereum.
A really cool example of using these deposit transactions in non standard ways, that we believe Zora pioneered, is their “bridge & mint” flow. When bridging via the Zora frontend they actually encode a contract call to be executed on the L2, calling
mint()on an NFT contract. So by simply bridging ETH over to Zora you get an NFT along with your ETH.
For a more comprehensive understanding of deposits, please refer to the Optimism specs document on deposits.
So now with all that context, we land on the topic of forced withdrawals.
What we call a forced withdrawal in the Superbridge is actually just a normal withdrawal but initiated from Ethereum. After the deposit transaction that wraps the actual withdrawal transaction has been confirmed on the L2, the withdrawal proceeds exactly as any normal withdrawal would.
The option to enable forced withdrawals is available when withdrawing assets vai the Superbridge. You’ll see the Network fee line item increase when selecting this option because you’ll need to pay Ethereum gas fees.
We definitely appreciate that forced withdrawals can be tough to wrap your head around, but hopefully with a deeper understanding of deposit and withdrawals transactions, the flow and option in Superbridge makes a little more sense.