A rollup can retain an alternative transaction route while its usual sequencer is unavailable. That does not mean treasury operations continue at their ordinary speed. Forced inclusion changes the path by which an instruction reaches the rollup. The institution still needs the right permissions, a valid instruction, funding on the parent chain and enough time for the fallback mechanism. Those conditions determine whether the route can support a particular obligation.
Availability is a separate operating question
A sequencer receives and orders transactions for a rollup. If that service stops accepting a firm's transactions, the immediate issue is access to execution. A previously settled balance may remain intact while a new collateral adjustment cannot get through. The distinction matters because controls concerned only with custody loss or settlement finality can miss an inability to act within a deadline.
Our overview of Ethereum layer-two rollups explains the broader architecture. An outage review should narrow its attention to the actual submission routes available on the chosen chain. Some incidents affect the sequencer; others affect an RPC endpoint, a batch poster or an application interface. The same user-facing timeout can have different causes and different remedies.
Arbitrum's sequencer documentation distinguishes sequencing, execution and posting to the parent chain. It also describes delayed messages and force-inclusion thresholds that depend on protocol parameters. This illustrates why a runbook should identify the relevant contract and configuration. A generic claim that transactions can be forced through does not specify when a particular chain will accept a particular message.
Two designs, no universal stopwatch
The OP Stack's forced-transaction guide describes submitting through the OptimismPortal on Ethereum. Under prolonged sequencer downtime, derivation can proceed with deposit transactions after the sequencing window. The guide currently describes a twelve-hour window for that flow. That is a documented design example, not a timing promise for every OP Stack deployment or every incident.
Arbitrum uses a delayed-inbox route and a force-inclusion mechanism with its own conditions. Its documentation describes a censorship-timeout buffer and configurable parameters. The operational lesson is to read the deployed chain rather than import a familiar number from another rollup. Upgrades and governance changes can alter the relevant assumptions, so the runbook needs a dated configuration record.
The OP Stack derivation specification shows why waiting exists: nodes reconstruct the layer-two chain using parent-chain data and defined sequencing rules. The fallback is part of a derivation process, not a privileged operator button that creates immediate normal service. A business deadline shorter than the applicable fallback delay needs a response outside that route.
A hypothetical margin deadline
Suppose a hypothetical treasury must add collateral within two hours to a position on a rollup. Its usual submission endpoint times out. The team has heard that the chain offers forced inclusion, but its tested fallback can take longer than the remaining deadline. The existence of the route does not make the position operationally liquid within those two hours.
The desk's earlier decision should have accounted for that gap. Possible designs include maintaining additional collateral, setting exposure limits around the delay or arranging another source of liquidity. Which choice is appropriate depends on the contract and institution. The point is to compare the obligation's response time with demonstrated movement capacity, rather than count a protocol fallback as immediate access.
Now suppose the team has six hours and a fallback that may fit. It still needs to construct the instruction through the alternative route, account for how the originating sender is represented, and confirm that the target application accepts that context. A route that can carry arbitrary calls does not mean every existing signing workflow will produce an equivalent authorised action without adaptation.
Map the path all the way to application state
A useful runbook begins with the account, asset and action that must remain available. It identifies the alternative submission contract, the exact message format, funding requirements, waiting conditions and observation method. It ends with evidence that the intended application state changed. Recording only the parent-chain transaction leaves a gap between submission and the business outcome.
Sender semantics deserve specific engineering review. Some cross-layer routes treat contract senders differently from ordinary accounts. A multisignature wallet, delegated account or module may therefore require a different integration from a simple key account. The institution should test its own custody and permission arrangement, rather than rely on a demonstration performed with an unrelated developer wallet.
The fee reserve must sit where the fallback spends it. A rollup wallet can hold ample value while its parent-chain submitting account lacks the native currency needed for the alternative route. An emergency top-up can itself depend on unavailable signers or another provider. The reserve policy should cover the whole path, including authorisation to use it during abnormal fee conditions.
Observation requires independence too. If the outage exercise relies on the same unavailable provider to confirm every step, operators cannot distinguish waiting from failure. Identify how the team will observe parent-chain inclusion, the applicable delay, rollup derivation and application execution. Uncertain status should suspend duplicate submissions until the possibility of repeated effects is understood.
The drill should begin with ordinary service unavailable
Start the exercise by disabling the normal transaction submission route. Give operators a previously approved business instruction and the actual account architecture. Measure the time to identify the incident, obtain necessary approvals, construct the fallback and verify its effect. A test that begins with a prebuilt transaction and a developer already logged into the right tools measures a different capability.
Include an application-level rejection. A forced instruction may reach the chain yet fail because a deadline expired, a position changed or a permission was absent. That outcome is technically informative and commercially unsuccessful. The response procedure must separate successful inclusion from successful execution, and successful execution from meeting the original obligation.
Include recovery while a fallback is outstanding. The usual sequencer may resume before the alternative instruction has completed. Operators need to know whether to wait, submit another action or cancel a business plan. Otherwise restored service creates a second incident through competing instructions. Preserve the identifiers connecting all attempts to the same obligation.
Use delay in exposure decisions
For a discretionary transfer, waiting for the alternate route may be acceptable. For a leveraged position or a payment with penalties, the same delay may exceed the institution's tolerance. Exposure limits should therefore consider the time required to regain control, the resources needed and the consequences of unsuccessful execution. The value of the assets is only one input.
Digital-asset recovery drills provide a framework for testing the resulting process. Forced inclusion becomes meaningful evidence when the team can show that its actual account performed its actual class of action through the fallback. A protocol escape route and an operational continuity capability are connected by that demonstration.