Test a rollup exit route on paper before funds depend on it

Practical guide · prepared 19 September 2026. Sources were checked for this workflow; linked interfaces and policies can change. Research scope.

The exit is a sequence, not a button

A bridge interface may offer a fast quote from a liquidity provider and a canonical rollup withdrawal on the same page. They are different promises. The first depends on a counterparty providing destination liquidity. The second depends on rollup contracts accepting a message or proof after defined delays. Due diligence starts by mapping the canonical path even if a faster route is normally used.

Write the route as state transitions

1. Name the exact L2 asset contract and its L1 counterpart. Use the stablecoin identity workflow where symbols collide.
2. Identify the L2 contract that burns or escrows the asset and emits the withdrawal message.
3. Identify the L1 portal, outbox or gateway that proves and finalizes the message.
4. Record every required actor and transaction: initiate on L2, wait for an output or assertion, prove on L1, wait through the challenge or maturity period, then finalize on L1.
5. Estimate gas in both native assets and ask what happens if the sequencer, normal relayer, frontend or RPC is unavailable.

The OP Stack specification separates initiation, proving and finalization. Its configuration specification requires a seven-day proof-maturity delay and also documents guardian-administered dispute settings. Arbitrum Nitro describes L2 tokens being burned, a message reaching the L1 Outbox, and escrowed L1 tokens being released after confirmation. It also describes a Delayed Inbox through which users can eventually force inclusion without the sequencer.

Hypothetical route review

Hypothetical: Rollup Red's website says 'withdraw in minutes' through Partner FastBridge. The canonical contracts require an L2 initiation, an L1 proof when the relevant output is available, a seven-day maturity period and an L1 finalization transaction. The fast route is currently cheaper, but its terms let the provider pause fills. Record two routes: a provider-dependent fast exit and a slower canonical exit. Budget L1 gas before entering; holding only the L2 token can leave a user unable to perform the final L1 steps during congestion.

Check the failure route

Document whether a user can submit through L1 when the sequencer censors, who posts state commitments, who can challenge them, and whether contracts can be upgraded or paused during an exit. Then follow those roles using the admin-tracing guide. A theoretical escape hatch is weaker if it requires unpublished tooling, unavailable data or a privileged actor. Conversely, a centralized frontend going offline is not the same as the contracts becoming unusable if independent transaction construction is documented.

Decision criteria and limits

A satisfactory paper test names contracts, transactions, delays, fee assets, permissioned roles and a non-frontend submission method. Mark any missing element unresolved. Do not claim to have tested an exit unless an actual, authorized test was performed and recorded; none was performed for this guide. Specifications can diverge from a particular deployment or change through upgrades. The workflow does not predict bridge liquidity, prove fault-proof correctness or guarantee liveness during an emergency. It turns the general risks in the rollup mechanism note into an exit-specific checklist.