## 2. Proof system

Arbitrum One — project-source snapshot checked 2026-10-27.

- **Live optimistic fraud proofs: BoLD (Bounded Liquidity Delay).** The overview identifies BoLD as an optimistic-rollup dispute protocol active on Arbitrum One; it replaces the previous allowlisted fraud-proof dispute protocol. Source: [BoLD overview](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction).
- **Interactive proving, not validity/ZK proving:** parties bond on state assertions, narrow disagreements through an interactive fraud-proof game, and use an Ethereum-verified one-step proof to resolve the disputed computation. Anyone can initiate a challenge against an unconfirmed assertion. Source: [BoLD technical deep dive](https://docs.arbitrum.io/how-arbitrum-works/bold/bold-technical-deep-dive).
- **Permissionless proposals and challenges, subject to bonding:** the FAQ says anyone can propose assertions and challenge invalid ones, including through pooling contracts; assertion proposers must supply a bond. This is distinct from free watchtower validation. Source: [BoLD FAQ](https://docs.arbitrum.io/how-arbitrum-works/bold/bold-faq). The Foundation independently labels Arbitrum One validation permissionless and says any node implementing BoLD can join. Source: [Progressive decentralization, validation](https://docs.arbitrum.foundation/state-of-progressive-decentralization#2-validation-decentralization-status).
- **Ordinary assertion challenge window:** the chain-specific parameters list **45,818 Ethereum blocks, approximately 6.4 days**, and an assertion-proposal minimum bond of **3,600 ETH**. Source: [Chain information, chain parameters](https://docs.arbitrum.io/chain-info#chain-parameters). The technical deep dive says an honest claim can confirm after 6.4 days and a malicious claim must be challenged within that window. Source: [BoLD technical deep dive](https://docs.arbitrum.io/how-arbitrum-works/bold/bold-technical-deep-dive).
- **Contested confirmation takes longer:** the overview bounds dispute resolution by two challenge periods, a two-day Security Council grace period, and a small computation allowance. The same page also describes challenges as concluding within a 6.4-day window; that sentence should not be substituted for its longer overall bound. Source: [BoLD overview](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction).
- **Timing discrepancy in generic adoption guidance:** the BoLD configuration guide calls the default challenge period 6.4 days, but its parameter table recommends seven days for both `confirmPeriodBlocks` and `challengePeriodBlocks`. Those generic recommendations differ from the chain-specific 45,818-block figure above; they are not evidence that Arbitrum One currently uses seven days. Sources: [BoLD adoption and parameter table](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bold), [Arbitrum One parameters](https://docs.arbitrum.io/chain-info#chain-parameters).
- **BoLD mainnet activation:** the Foundation records Arbitrum One's BoLD upgrade as approved and executed on **2025-02-12 at 14:00:11 UTC**. This is the BoLD activation date, not a claimed date for the first fraud proofs of any kind. Source: [Network upgrades, Arbitrum BoLD row](https://docs.arbitrum.foundation/network-upgrades#network-activation-statuses).

## 3. Exit window and upgrades

- **L1 upgrade authority:** Arbitrum One's chain owners, the **ArbitrumDAO and Security Council**, can upgrade associated L1 contracts and core proxies. DAO software updates and chain-owner actions require Constitutional AIPs. Source: [Constitution, sections 1–2](https://docs.arbitrum.foundation/dao-constitution).
- **Ordinary exit opportunity:** after approval, successive waits are **eight days on L2**, L2-to-L1 message finalization of **at least one challenge period**, and **three days on L1**. The Constitution says these let users initiate and complete withdrawals before implementation. Source: [Constitution, phases 4–7](https://docs.arbitrum.foundation/dao-constitution).
- **Security Council:** **12 members; 9-of-12 approval** for emergency upgrades with **no delay**, hence no guaranteed pre-upgrade exit window. Non-emergency upgrades also require **9-of-12**, skip phases 1–3, and follow delayed phases 4–7. Source: [Constitution, section 3](https://docs.arbitrum.foundation/dao-constitution).
- **Conflicting exit-language caveat:** the progressive-decentralization page says users have several weeks to withdraw if a malicious governance proposal passes **or nine council members are compromised**. Its blanket council wording conflicts with the Constitution's explicit no-delay emergency power. Do not interpret it as an unconditional exit guarantee. Sources: [Progressive decentralization, chain ownership risks](https://docs.arbitrum.foundation/state-of-progressive-decentralization#1-chain-ownership), [Constitution, emergency actions](https://docs.arbitrum.foundation/dao-constitution).
- **Named L1 control contracts:** the Foundation's deployment directory lists an Ethereum **L1 Upgrade Executor** and **L1 Timelock**, alongside the L2 Core Timelock. Source: [DAO contract addresses, DAO Governance](https://docs.arbitrum.foundation/deployment-addresses).

## 4. Data availability

- **Ethereum DA, using blobs or calldata.** In Rollup mode all transaction data is included in parent-chain transaction calldata or blobs; the documentation explicitly gives Ethereum mainnet for Arbitrum One as its example. AnyTrust's external Data Availability Committee is documented as a different mode. Source: [Data availability, Rollup and AnyTrust modes](https://docs.arbitrum.io/run-a-node/data-availability).
- **Blob posting with calldata fallback:** Nitro's architecture documentation says the official transaction sequence is posted to Ethereum as EIP-4844 blobs when enabled, supported and economically priced, otherwise as calldata. Source: [Inside Arbitrum Nitro](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro). ArbOS 20 Atlas added blob-format posting support, explicitly including Arbitrum One. Source: [ArbOS 20 Atlas, EIP-4844 notes](https://docs.arbitrum.io/run-a-node/arbos-releases/arbos20).
- **Code corroboration of both paths:** `SequencerInbox.sol` implements `addSequencerL2BatchFromBlobs` and a calldata path through `addSequencerL2BatchFromOrigin` / `addSequencerL2BatchFromCalldataImpl`. These demonstrate stack capabilities; the repository's `main` branch alone does not establish the implementation currently deployed on Arbitrum One. Source: [OffchainLabs Nitro contracts, SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol).

## 5. Sequencer and forced inclusion

- **Centralized sequencer; operator attribution differs.** The developer FAQ calls Arbitrum One's sequencer a centralized entity maintained by **Offchain Labs**. Source: [Arbitrum FAQ, sequencers versus validators](https://docs.arbitrum.io/get-started/faq). The Foundation instead says the sequencers are maintained by the **Arbitrum Foundation**, with governance able to select replacements. Both describe centralized sequencing; these pages do not reconcile the operational roles. Source: [Progressive decentralization, sequencer ownership](https://docs.arbitrum.foundation/state-of-progressive-decentralization#3-sequencer-ownership).
- **L1 bypass exists:** send a signed child-chain transaction to Ethereum's **Delayed Inbox** using `sendL2Message` or `sendL2MessageFromOrigin`; after its force-inclusion window, anyone can call **`SequencerInbox.forceInclusion`** to advance waiting messages without the sequencer. Source: [Forced transactions](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/forced-transactions).
- **Delay:** the detailed forced-transactions page gives Arbitrum One `delayBlocks = 7200` Ethereum blocks, approximately **24 hours** at 12 seconds per block. The window is the smaller of that limit and the enabled delay buffer. Prolonged censorship drains the buffer; its floor is **150 blocks, approximately 30 minutes**, with a maximum buffer of 14,400 blocks. Inclusion opens after the applicable deadline block. Source: [Forced transactions, timeline and window settings](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/forced-transactions).
- **Code corroboration:** `forceInclusion` is external with no sequencer-only caller restriction. It verifies the delayed-message accumulator, applies the delay buffer when enabled, and rejects inclusion while the message's L1 block plus the applicable delay is greater than or equal to the current block. Source: [OffchainLabs Nitro contracts, SequencerInbox.sol](https://github.com/OffchainLabs/nitro-contracts/blob/main/src/bridge/SequencerInbox.sol).
- **Conflicting configuration page:** additional-configuration guidance says Arbitrum One uses **`delayBlocks: 5760` and `delaySeconds: 86400`**, whereas the chain-information table and detailed force-inclusion guide give **7200 blocks / 24 hours**. The discrepancy is unresolved here; the detailed guide says force inclusion checks block numbers rather than seconds. Sources: [Additional configuration, maximum time variation](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/additional-configuration-parameters), [Chain parameters](https://docs.arbitrum.io/chain-info#chain-parameters), [Forced transactions](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/forced-transactions).
- **Scope of censorship resistance:** the guide warns that the chain owner can allowlist or pause the Inbox. Forced inclusion ensures processing, but a signed transaction can still be dropped for invalid nonce, insufficient funds or other validation failures. Source: [Forced transactions, ownership caveat and missing receipts](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/forced-transactions).

## 1. Stage

- **Project's Stage 2 roadmap:** the BoLD overview explicitly discusses the L2BEAT framework, identifies unrestricted state validation and fraud-proof submission as a Stage 2 requirement, and describes BoLD as charting a course toward Stage 2 recognition. That is roadmap language, not a statement that Arbitrum One has achieved Stage 2. Source: [BoLD overview, “BoLD enables Arbitrum to become a Stage 2 Rollup”](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction).
- **Stage 1 wording has limited scope:** the Foundation's Orbit introduction includes “Stage 1 rollup” among stack benefits and calls One and Nova the first Orbit chains. This is stack-level wording, not an unambiguous, dated declaration of Arbitrum One's current L2BEAT stage. Source: [Creating new Arbitrum chains, Arbitrum Orbit](https://docs.arbitrum.foundation/new-arb-chains#arbitrum-orbit).
- **Decentralization direction:** Nitro's architecture page describes Arbitrum One's sequencer as not decentralized and says sequencing will become decentralized over time. Source: [Inside Arbitrum Nitro, sequencer and decentralized-sequencing discussion](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro).

## Not found

- **NOT FOUND — an unambiguous, dated project-doc declaration of Arbitrum One's current numeric L2BEAT stage, or a stage-change date during 2026-04-27 through 2026-10-27.** Pages tried: [BoLD overview](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction), [Progressive decentralization](https://docs.arbitrum.foundation/state-of-progressive-decentralization), [Creating new Arbitrum chains](https://docs.arbitrum.foundation/new-arb-chains), [Network upgrades](https://docs.arbitrum.foundation/network-upgrades). Roadmap and stack-level wording are reported above without assigning a stage.
- **NOT FOUND — the original mainnet activation date of Arbitrum One fraud proofs before BoLD.** The upgrade date found establishes BoLD activation only. Pages tried: [BoLD overview](https://docs.arbitrum.io/how-arbitrum-works/bold/gentle-introduction), [BoLD adoption](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bold), [Network upgrades](https://docs.arbitrum.foundation/network-upgrades).
- **NOT FOUND — a reconciliation of the sequencer-maintainer attributions, the 5760-versus-7200-block configuration statements, or the generic seven-day versus chain-specific 6.4-day challenge guidance.** Both versions and their source pages are preserved in the relevant sections. Pages tried: [FAQ](https://docs.arbitrum.io/get-started/faq), [Progressive decentralization](https://docs.arbitrum.foundation/state-of-progressive-decentralization), [Additional configuration](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/additional-configuration-parameters), [Forced transactions](https://docs.arbitrum.io/how-arbitrum-works/deep-dives/forced-transactions), [Chain information](https://docs.arbitrum.io/chain-info), [BoLD adoption](https://docs.arbitrum.io/launch-arbitrum-chain/chain-config/validation/bold).