A rollup can keep an Ethereum route open for users whose transactions are stuck at the sequencer. That route handles transaction inclusion. Getting funds back to Ethereum also depends on whether the rollup’s withdrawal can be proven and completed under the bridge rules.
Summary
- Base and Arbitrum One offer Ethereum-side transaction inclusion routes when the usual sequencer is unavailable, but the resulting withdrawal still has to satisfy the official bridge’s rules.
- A transaction already included before an outage may be further along than a new withdrawal. The state published to Ethereum and the proof status determine which step is next.
- ETHBEAT rates both rollups Stage 1, while its assessments list different protections for regular upgrades. Neither assessment gives users an exit window under the emergency path described.
- Base’s Azul upgrade introduced new proof options, while Arbitrum’s Delayed Inbox gives users a way to submit messages through Ethereum. Those features address different parts of a withdrawal.
- A fast bridge can use separate liquidity to pay a user, and an externally issued token can have its own redemption rules. Both need to be considered alongside the official bridge.
Consider two users who hold ETH, one on Base and one on Arbitrum One. Both use the official bridge, but they try to leave at different points in an outage. One withdrawal is already in the rollup’s records. The other still needs to get a transaction accepted.
Ethereum can provide an alternative to the normal sequencer route. Whether that gets either user to the end depends on the bridge’s next step and whether the people able to change or pause the contracts have acted.
A withdrawal has more than one step
In ordinary operation, a user begins by sending a withdrawal transaction on the rollup. The sequencer orders it with other transactions. The bridge withdrawal can then be established on Ethereum once the relevant rollup state is available and the applicable proof and waiting requirements are met.
The two transactions can feel like one action in a wallet. The first records the withdrawal on the rollup. A later action can complete it on Ethereum. A user who can see the first transaction in an explorer has evidence that it was included, even if the funds are still unavailable on Ethereum.
The route around the sequencer
Arbitrum’s forced transaction documentation describes a route through its Delayed Inbox on Ethereum. A transaction can wait there before it becomes eligible for forced inclusion. The period is separate from the time needed to complete an Ethereum withdrawal.
Base’s derivation specification describes deposits derived from Ethereum, including the protocol’s route for force inclusion. The useful comparison is whether the user can initiate the necessary action through Ethereum, how long the protocol may take to include it and what still has to happen after inclusion.
The fallback can involve an Ethereum transaction fee. It also depends on the user or the service acting for them being able to submit the right message. A wallet with a broken connection to its normal endpoint may need a different interface to use a functioning chain route.
An emergency upgrade tests a different protection
An outage raises a question about whether a transaction can get onto the rollup. An upgrade raises a question about who can change the contracts that determine whether the withdrawal will be honoured. A forced transaction route does not itself preserve the existing rules until a user can complete the withdrawal.
ETHBEAT lists Base and Arbitrum One as Stage 1. Its assessment shows no exit window for Base and distinguishes regular from emergency upgrades for Arbitrum One. Arbitrum’s regular path lists a 10-day window, while the emergency path has no such window.
That difference is why a Stage 1 rating alone cannot answer how long a user has to leave. A notice period needs to be considered with the time needed to start, prove and finalise a withdrawal. The relevant period is the time left after accounting for the steps the user needs to complete.
A third-party bridge adds its own conditions
A fast bridge can pay the user from liquidity it already has on Ethereum while it settles its own position later. That can make the visible withdrawal faster in normal operation. It also introduces a provider whose liquidity and operating policy matter when the rollup is under stress.
The asset matters too. A balance issued through a third-party bridge can depend on that bridge’s contracts even if it is held on Base or Arbitrum. An assessment of the rollup’s official exit mechanism cannot by itself establish what an external issuer will redeem.
A fair comparison would take the same kind of asset through both official bridges and record the first inclusion, proof and finalisation steps. Then it would compare what changes if the sequencer stops and what an emergency upgrade can do before either withdrawal finishes.
Start with the same withdrawal on both networks
Take a user who holds native ETH on each network and wants the ETH back on Ethereum. Using the same asset makes the comparison easier because it avoids the separate redemption rules that can apply to wrapped tokens. The official bridge still needs evidence that the withdrawal began and that the state containing it has been accepted under the rollup’s rules.
In ordinary operation, the user submits an instruction on the rollup. Its inclusion produces a record the withdrawal system can later recognise. The user or an interface acting for them can then carry out the steps required on Ethereum. The funds become available on Ethereum once the relevant bridge contract executes the withdrawal.
The wallet can show several kinds of progress. It can show that the sequencer accepted the transaction, that a batch reached Ethereum or that a withdrawal is ready for a later step. Those labels describe different events. An interface that shows a transaction as confirmed may still be describing its status on the rollup.
A withdrawal that started before an outage is also different from one the user has yet to initiate. If the transaction and the state needed to support it already reached Ethereum, the remaining work may take place there. If the only evidence is a recent response from the sequencer, the user still needs the relevant data and state to make it through the rest of the system.
The distinction helps explain why the first useful question during an outage is where the withdrawal stopped. A missing rollup transaction calls for a route to inclusion. A withdrawal already recorded on the rollup can be waiting for the proof or finalisation stage. The next action depends on which of those stages the network has reached.
What changes when the sequencer stops
The sequencer normally gives the user a quick route to have a transaction ordered. If the service stops responding, a submitted transaction can fail to appear even though Ethereum continues to operate. A route through Ethereum gives users a way to put a message into the rollup’s inputs without waiting for its normal endpoint to return.
On Arbitrum One, Ethereum records messages in the Delayed Inbox. A sequencer can include them in the normal course. If a message stays there beyond the applicable wait, the forced inclusion route can make it part of the sequence. The Ethereum transaction recording the message and the rollup transaction executing it remain separate observations.
On Base, deposits recorded on Ethereum become inputs for the rollup’s derivation rules. The term deposit can be misleading in this context because it also refers to a message type through which an Ethereum transaction can trigger action on the rollup. The user’s intended rollup operation still has to execute successfully after inclusion.
ETHBEAT’s project pages describe the delay under the conditions they model. The estimate applies to the fallback step and can differ between the two networks. It does not turn a rollup-to-Ethereum bridge into an immediate withdrawal. A final payout still depends on the bridge accepting the resulting state and completing its own steps.
The user also needs the means to submit the Ethereum transaction. Someone whose entire balance is on the rollup may need access to ETH on Ethereum for the fallback. An application that handles this for users in ordinary conditions can face the same practical constraint if it relies on the failed endpoint or does not expose the Ethereum route.
A recipient should also distinguish a failed request from a successful onchain submission that has yet to take effect. A transaction hash from Ethereum establishes that the fallback message was submitted if its receipt confirms it. It does not establish the outcome of the later execution on the rollup.
When the network keeps producing blocks but withdrawals stall
A network can produce transactions while another part of the withdrawal process is delayed. The contracts on Ethereum need a recognised account of what happened on the rollup. A delay in posting or establishing that state can leave users waiting after the sequencer has already returned a successful result.
The distinction comes from the different jobs involved. The sequencer orders transactions. Data availability lets other parties reconstruct what was ordered. The proposal and proof systems establish which resulting state the Ethereum contracts should recognise. A service can perform one of those jobs while another is waiting.
For an observer, a block explorer still showing activity is therefore an incomplete test. The observer can compare recent transaction inclusion on the rollup with the Ethereum records for the state or claims that withdrawals depend on. A gap between the two helps identify whether the bottleneck is earlier or later.
ETHBEAT distinguishes sequencer failure from proposer failure because the fallback for one does not necessarily resolve the other. Its categories are a way to see which actor can step in when the usual operator is absent. They should be read with the conditions and delay described for each project.
The same principle applies to reports of degraded service. A front end can be unavailable while contracts remain callable. An explorer can lag while the chain advances. A bridge interface can disable submissions during an incident even if another interface can still reach the contracts. Each case should be checked at the layer where it occurs.
Crypto.news reported that Base experienced a 33-minute outage in August 2025. That incident provides a case for asking which user actions were interrupted and which alternatives remained available. Its duration does not establish how a future event involving a different component would affect withdrawals.
The wait after inclusion belongs to the bridge
Once a withdrawal is in the rollup’s state, it still has to clear the bridge’s proof and finalisation conditions. Optimistic designs give participants an opportunity to challenge an incorrect claim. The delay can be a deliberate part of that process rather than a sign that the sequencer is offline.
The timing starts from the event defined by the bridge, which need not coincide with the instant the user first clicks withdraw. The wait can depend on when the relevant output or claim is available and whether the required proof has been submitted. A user can spend time waiting before the challenge period that appears in a bridge description begins to matter.
A wallet’s countdown may therefore describe an estimate rather than an unconditional payment date. It can depend on normal posting and proof activity continuing. If the state is disputed, the time to finality can change even though the withdrawal instruction itself already appears on the rollup.
Arbitrum’s proof system and Base’s proof design have different implementation details. The practical comparison for a user is who can submit a claim, who can challenge it, and what happens if the actor that normally submits the next claim stops. The same word, withdrawal, covers different sequences across those systems.
The delay also affects comparisons with third-party bridges. A service that can pay the user immediately on Ethereum is using its own liquidity or a separate network of participants. The fast payment can complete before the official withdrawal behind it is eligible to settle.
The user then relies on the third party’s ability and willingness to make the payment. If liquidity is exhausted or the provider stops accepting requests, the speed quoted for routine trades may no longer apply. The underlying rollup’s exit protections and the commercial service’s payout conditions remain distinct.
The upgrade question is about which rules apply tomorrow
A sequencer failure prevents a user from reaching the normal route into the chain. An upgrade can change the rules governing the route itself. That makes the upgrade delay relevant even if the sequencer is healthy and every transaction is being accepted.
Under a regular governance process, an announced upgrade may have to pass through a delay before it can take effect. During that period users can assess the proposal and begin to leave if the bridge remains open. The useful exit window is what remains after allowing for the normal withdrawal steps.
Under an emergency path, designated signers can sometimes act without the regular delay. That can help respond to a security incident quickly. It also gives users a different guarantee from the one they see when governance takes its ordinary route.
The Arbitrum One assessment lists ten days for the regular path and no exit window for an emergency upgrade. The Base assessment lists no exit window. The headline stage rating can be the same while those powers differ in practice.
A pause is another action to distinguish from an upgrade. A pause can stop a specific operation under existing contract rules. An upgrade can replace or change those rules. The signer and threshold required for a pause may differ from the signer and threshold for a new implementation.
Crypto.news covered a concrete example of emergency authority when Arbitrum’s Security Council moved funds linked to the Binance hack. That case concerned identified funds and a temporary contract change. Its relevance here is that emergency authority can be exercised in practice and can be separate from the later process that determines where funds go.
How to read Stage 1 without mistaking it for an exit guarantee
Stage classifications group several dimensions of a rollup. They indicate how far a system has moved away from dependence on operators or councils under the framework’s criteria. A stage label cannot supply the answer for every failure mode because each protection addresses a different job.
For a user, the important details are the conditions that apply to their transaction. A sequencer fallback matters if the transaction cannot be included. The ability to propose state matters if the rollup’s usual proposer stops. An upgrade delay matters if someone can change what the bridge will do while the user waits.
Data availability belongs in the same comparison. If the data needed to reconstruct the rollup are accessible on Ethereum, another participant has a basis for following the chain. The existence of the data does not itself carry out a proof or submit an Ethereum transaction on the user’s behalf.
Base and Arbitrum One can both offer a route through Ethereum for a sequencer problem while retaining different permissions around upgrades. A practical assessment records both instead of averaging them into a single score. A user trying to leave needs the weakest relevant step for the event they are facing.
The assumptions also vary with the token. Native ETH can follow the official bridge’s own rules. A token that arrived through a third-party contract can add issuer or bridge controls. Two wallets on the same rollup can face different redemption conditions even when their interfaces show both balances in the same dollar terms.
The Ankr bridge incident provides a separate example of how bridge logic can determine whether a withdrawal is valid. It concerned a different system. Its relevance is the distinction between activity on a chain and the rules the bridge uses to accept messages and release assets.
What an exit comparison can establish
Compare two users who initiate ordinary withdrawals before a sequencer outage. If each withdrawal is already part of state available to the bridge on Ethereum, the remaining steps depend on the proof and finalisation process. The outage may have little direct effect on an already matured withdrawal if Ethereum execution remains available.
Now move the outage earlier. Neither user has a withdrawal transaction included. Both need to reach the rollup’s Ethereum-side route or wait for normal service. The time to inclusion can differ, and the bridge’s own wait comes afterwards.
Finally, imagine an emergency contract action while the withdrawals are pending. The relevant evidence becomes the authority behind the action, the exact contracts affected and which steps the new configuration permits. A previously included transaction may still need the bridge to recognise it under the rules in force when the user tries to finish.
These cases show why a fair comparison starts with the same state. A user who submitted a message to Ethereum but has yet to see rollup execution should not be compared directly with someone whose bridge proof was already accepted. The clocks start at different events.
Crypto.news has reported on efforts to make Ethereum rollups work together. A smoother front end can hide several steps in a normal transaction. Under stress the user benefits from knowing which parts of the operation take place on which chain and who is responsible for each part.
Crypto.news’s coverage of the Binance-linked Arbitrum recovery proposal also shows why a governance action should be read together with the transaction it authorises. A proposal describes the intended result. Ethereum and rollup records show when and where it was executed.
An exit route is useful only to the extent that a holder can use it from their current position. The clearest record identifies the asset, the chain it sits on, the transaction already completed and the party or contract controlling the next step. That record tells a user whether the remaining wait belongs to the sequencer, the bridge or an authority able to change either.
Why a faster proof does not necessarily shorten every exit
Base’s Azul upgrade introduced new proof options. Crypto.news reported a potential path to one-day withdrawals. A target or proof capability has to be distinguished from the withdrawal time a particular user can rely on under the active configuration.
A proof can help establish the state on which a withdrawal depends. The bridge can still apply other conditions before releasing funds. The sequence may also vary according to which proof path the network uses and what happens when that path is unavailable.
An exit comparison should therefore state the path it is measuring. An optimistic path can have a challenge period. A route using a different proof may shorten part of the process. An upgrade risk concerns whether the contracts or permissions governing either route can change before it finishes.
An Ethereum withdrawal also requires a transaction that can be submitted and executed on Ethereum. A third-party site may offer to perform that step, but its ability to accept a request is separate from whether the official contract can process it. A user who sees the action become available still needs a wallet or service able to submit it.
The distinction becomes important if the user is holding assets on behalf of an application or a client. A treasury may require several approvals before any Ethereum action. An ordinary user may need a wallet connection and gas. The protocol’s available exit time and the time the person needs to act can differ.
What the public record can show after an outage
An incident account can start with the last normal sequencer response and the first delayed transaction. It can then identify whether data and state continued to reach Ethereum. The records can help explain why some users saw an interruption while others could still finish earlier withdrawals.
The most useful timeline also names the application and the asset involved. A wallet reporting stale balances is different from a bridge refusing to accept a finalisation transaction. A third-party provider pausing a payout is different from the official bridge changing its rules.
Crypto.news’s coverage of an emergency intervention on Arbitrum illustrates the need to separate an action performed by a council from the governance process that follows. The existence of an Ethereum record can establish that a contract action occurred. It does not eliminate the need to read which authority performed it and what it affected.
The direct answer to the withdrawal question depends on when the failure happens. Before inclusion, look at the Ethereum fallback and the delay attached to it. After inclusion, look at the state, proof and finalisation requirements. During an emergency change, the authority to pause or modify contracts becomes decisive even if the other systems are working.
A user may also have several withdrawals at different points in that sequence. One can be ready to complete while another is still waiting to be included. An outage notice that gives one expected recovery time cannot settle the status of both.
The withdrawal receipt is the final check
A bridge interface can label a withdrawal as ready before the user has submitted the transaction to complete it. The Ethereum transaction receipt is a separate record. For native ETH, the recipient can also check that the transfer reached the intended address and that the recipient can use it.
That distinction matters when a user retries an action after an outage. Two attempts to submit an instruction can produce different messages or only one accepted transaction, depending on how the requests were made. A wallet’s history can help the user identify which message the bridge recognises before they try the next step.
A rollup and a bridge can also recover on different schedules. The sequencer may resume while older withdrawals are still waiting for state or proof. New rollup transactions appearing again is evidence of service recovery for ordering, but users waiting to receive ETH on Ethereum still need to check their own finalisation status.
The same principle applies to an upgrade notice. An announcement may say a bridge is paused without changing what the rollup continues to process. Users need to identify whether the pause affects initiation, proof, finalisation or another operation. A single notice can matter differently for holders at different points in the process.
For the two users in the comparison, the final evidence is the same. Their official bridge withdrawals are complete when Ethereum records the release of ETH to the intended recipient. Everything before that tells them which part of the route is working and what remains to happen.
What to Watch
- Sequencer status: A status notice and rollup transaction records can show when normal ordering stopped and resumed.
- Ethereum inbox: A successful Ethereum receipt can establish that the fallback message was submitted and when it became eligible for inclusion.
- State publication: Ethereum records can show whether the bridge has the claim or output it needs to process the withdrawal.
- Emergency actions: The authorising signers, contracts affected and transaction time determine whether a pause or upgrade changed the user’s route.
- Asset backing: The token’s issuer and bridge determine whether the official withdrawal comparison applies to that balance.
FAQs
Can a user withdraw if the Base or Arbitrum sequencer is offline?
There are Ethereum-side routes for including transactions when the usual sequencer is unavailable. Inclusion is the first requirement for a new withdrawal. The official bridge still needs the relevant state and any required proof and waiting period before it releases funds.
Does forced inclusion mean funds arrive immediately on Ethereum?
Forced inclusion helps the user get a transaction into the rollup. It does not replace the bridge’s rules. The user should distinguish the Ethereum receipt for the fallback message from the later evidence that the rollup withdrawal executed and can be finalised.
Why can a withdrawal that started earlier still complete?
If the withdrawal already has the required accepted state and has cleared its waiting period, the remaining action may take place on Ethereum. A sequencer outage can have a different effect on a user whose transaction was never included or whose proof is still waiting for state.
What does a Stage 1 rating tell the user?
It describes the rollup under a framework that assesses several kinds of dependence on operators and privileged actors. The project-level risk details are needed to find the particular protection relevant to an outage, a proposal delay or a contract change.
What does a ten-day exit window mean for Arbitrum?
ETHBEAT lists that window for the regular upgrade path. The framework accounts for time needed to use the withdrawal route. The emergency path can operate without that window, which makes the authority and timing of the particular upgrade important.
Can a faster third-party bridge bypass a stalled official withdrawal?
A third-party service may be able to pay from its own liquidity under normal conditions. Its ability to do so during an outage depends on the service, the asset and the liquidity it has available. The user takes on a separate set of conditions from those in the official bridge.
Why can two users on the same network face different exit times?
They may hold different assets or be at different steps in the withdrawal. One might already have a claim that can be completed on Ethereum, while the other still needs to get an instruction into the rollup or rely on a separate token issuer.
What does an emergency pause change?
It can stop the operation covered by the relevant contract permission. That differs from an upgrade, which can alter the rules the contract applies. To see whether a particular withdrawal is affected, check the action taken, the contracts involved and the point the withdrawal had reached.
Disclaimer: This article is for informational and educational purposes only and does not constitute financial, investment, legal or tax advice. Cryptocurrency activities carry risks, including loss of funds. Readers should conduct their own research and consult a qualified professional where appropriate. Information is current as of 10 November 2026 and may change as product terms, network rules or applicable law change.
Leave feedback about this