Arbitration and Optimism: Who can stop or reschedule your transactions? How long will it take?

Who controls transaction ranking rights on Arbitrum and Optimism?

On both the Arbitrum and Optimism networks, there is a single operator called a "sorter" that determines the order in which transactions are processed before final confirmation on Ethereum. Neither web document claims that the sorter can permanently block a transaction: Arbitrum's decentralized page states that its sorter can delay transactions for up to 24 hours and re-order transactions in a short period of time; Optimism's document states that reviewed deposit transactions can be enforced directly through Ethereum, and that enforced transactions are guaranteed to be included within 12 hours. On top of the sorter, each network also has independent overlays-DAO and multi-sign contracts on Arbitrum, Guardian roles on Optimism-that can completely suspend some system functions.

What does the sorter actually control?

According to Arbitrum's documentation on sorters and censorship resistance, the sorters are responsible for sorting incoming transactions and handling data packaging, compression, and publishing to Ethereum. It publishes a real-time data stream that provides users with what is called "soft finality" in the document-a temporary confirmation that relies on the honest behavior of the sorter and takes effect before transactions are actually finalized on Ethereum.

Optimism's architecture follows similar principles. According to its mandatory transaction document, in normal operation, the sorter regularly processes transactions and generates blocks. The OP Stack specification's architecture diagram shows how the resulting data reaches Ethereum: A batcher publishes a transaction batch to the batch inbox address on the L1 chain, and the L2 node then retrieves the data to deduce the specification chain. Currently, sorters are operated by the Optimism Foundation, and decentralized sorters are an active development priority-this statement comes from a third-party explanation and is not a statement in the Optimism main document or the OP Stack specification, and this article regards it as a single source.

Arbitrum bypass mechanism: delayed inbox and 24-hour limit

Arbitrum's sorter documentation describes a "deferred inbox" contract on Ethereum that the sorter monitors for finalized retriable transactions and messages submitted directly on the parent chain, and incorporates them into the transaction flow after confirmation. The document does not explicitly describe the delayed inbox as a universal anti-censoring bypass path for any user transaction; it mentions a separate feature,"review timeout," designed to "limit the negative impact of long-term sequencer reviews or unexpected downtime," but does not specify how it is triggered or how long it takes. In addition, the Arbitrum Foundation's progressive decentralization page states that the sorter can delay the inclusion of user transactions for up to 24 hours and re-order transactions in a short period of time, while emphasizing that the sorter "cannot compromise system security" or prevent the final execution of transactions. The evidence reviewed here does not clarify whether the 24-hour limit was achieved through delayed inboxes, review time-outs, or other mechanisms.

Optimism's bypass mechanism: mandatory trading and 12-hour window

Optimism's mandatory trading document gives a more complete timeline. Under normal operation, deposit transactions are included within 30 minutes-this is the "maximum time drift" of the network. If the sorter goes offline, users can submit transactions directly to the Optimism Portal contract on Ethereum, completely bypassing the sorter. According to the documentation, the next steps depend on the offline duration:

Less than 30 minutes: After the sorter is restored, transactions can still be implemented within the usual 30-minute window.
Between 30 minutes and 12 hours: Force transactions to stay on Ethereum until the sorter is back online, or until the 12-hour "sorting window" expires, whichever comes first.
Over 12 hours: Nodes begin to generate blocks deterministically, containing only transactions forcibly submitted to Ethereum, while ordinary sorter transactions wait for the sorter to catch up.

Optimism's documentation also describes the "sorter catch-up phase" after more than 30 minutes offline: L2 blocks are usually generated at a ratio of 6:1 (relative to Ethereum blocks), which is temporarily switched to 1:1 until the sorter finishes processing the backlog of tasks. The document describes the 12-hour limit as a deliberate trade-off-long enough to allow the sorter to recover without triggering L2 reorganization, but short enough to ensure eventual inclusion.

Who can override the sorter at the protocol level?

Under the sorter, each network has a separate layer of accounts that can operate on the protocol itself-a different question from who sorts individual transactions.

On Arbitrum, ownership of the chain-the power to upgrade core contracts, change system parameters, or suspend the system-is governed by the Arbitrum DAO and consists of ARB token holders and representatives. A Security Council could also exercise these powers: it is a "9 of 12 multi-sign wallet" that can act quickly in emergencies and adopt a slower process for regular upgrades, and its members are elected every six months by the DAO. The same document states that if the malicious DAO proposal passes, or nine Security Council members are breached, users will have several weeks to withdraw funds into Ethereum before the changes take effect. Currently, the verification of Arbitrum One runs on the BoLD protocol that does not require a license; while Arbitrum Nova is still licensed and protected by a six-member Data Usability Committee, whose members include Consensus Sys Software Inc., QuickNode Inc.、P2P.org、Google Cloud、Offchain Labs Inc. and Opensea Innovation Labs Private Limited. The foundation's Nova Risk Statement states that system security is compromised only when five of the six DAC members collude with the sorter.

On Optimism, the equivalent overlay is located in OP Stack's Ethereum-side contract. The OP Stack specification lists a Guardian role with the authority to suspend and unsuspend SuperchainConfig contracts and perform so-called "safety net actions" on Optimism Portal, Dispute GameFactory, and DelayedWETH contracts. The specifications document the existence and reach of the role, but do not state who currently holds it, how many parties are involved, or what thresholds are needed to act-a gap this article cannot be filled from existing evidence.

Work comparison

puts two published numbers together to compare: The Arbitrum Foundation's decentralized document states that sorters can defer user transactions for up to 24 hours before inclusion, but the same document does not explain the mechanism for this final inclusion. Optimism's mandatory trading guidelines document a shorter and more complete path: Users can submit deposits directly to the Optimism Portal contract on Ethereum, guaranteed to be included within 12 hours. These two numbers describe different things--Arbitrum's is the upper limit on latency, the underlying mechanism of which is unclear in the evidence gathered in this article;Optimism's is the well-documented end-to-end bypass path. Therefore, the comparison between 12 hours and 24 hours is an interpretation of the respective published figures for each project, rather than a claim that the two networks provide the same guarantees.

Common misconceptions

A common assumption is that once an L2 transaction appears as confirmed in the wallet, it has been settled and cannot be reordered or deferred. Both project documents indicate otherwise: Arbitrum's sorter data flow produces only "soft finality," which the document states relies on the sorter's honest behavior;Optimism's deposit process is explicitly designed around the possibility that the sorter may stop working or start reviewing. Bypass paths on the two chains exist because the underlying centralization-single-operator sequencing transactions-has not yet been eliminated, but only restrictions have been imposed.

What is not described in this article

The documents cited in this article describe design capabilities rather than event history. Neither Arbitrum nor Optimism's documentation, within the scope of this review, states whether the 24-hour delay window, the 12-hour sorting window, the Security Council's emergency multi-signing, or Optimism's Guardian suspension rights were actually used on the production network, or what happened after use.

The identities behind the two key coverage roles are not disclosed in this evidence: The OP Stack specification names the Guardian role and the operations it can perform, but does not say who holds the key or how many parties are involved. The composition of the Arbitrum Security Council is described only by the number of seats and election cycle, not by specific signatories.

This article covers Arbitrum One, Arbitrum Nova, and OP Mainnet. Other chains built based on OP Stack, such as Base, or chains built based on the Orbit framework of Arbitrum, can configure their own sorter ownership and suspend permissions even if they share the underlying codebase; the evidence gathered in this article does not apply to these chains.

Some source documents-including the Arbitrum Foundation's decentralized pages (labeled "Public Preview Documents" and subject to change) and Optimism's documentation and specifications pages-do not display a release date. The values describing these fixed protocol parameters are based on the version of the document at the time of review of this article; readers should verify it against the current page for subsequent reviews, rather than assuming that the content remains unchanged.

The fee and token allocation data about Optimism from the third-party interpretation site ChainClarity (including the 40% fuel cost reduction caused by the Bedrock upgrade and Optimism's token allocation percentage) is a research by the site and is not officially confirmed by Optimism. This article is only used as a single source of background information.