## Identity - Display name: **Base Chain**; L2BEAT describes Base as an **Optimistic Rollup** (purpose: **Universal**) with chain ID **8453**. - Host chain: **Ethereum**. - Total Value Secured: **$14.95 B USD**, as displayed when read on **2026-10-27 at about 14:23 UTC**; this is a changing dashboard value. - Badges: **EVM**, **Ethereum with blobs**, **Built on OP Stack**. ## 1. Stage - **Stage 1 — “Limited training wheels.”** L2BEAT's stated reason: “The project passes the walkaway test: users can exit in the presence of malicious operators even if the Security Council disappears.” - **Stage 0 — 6 requirements met**, as quoted from Base's checklist: 1. “A complete and functional proof system is deployed.” 2. “There are at least 5 external actors who can submit fraud proofs.” 3. “The project calls itself a rollup.” 4. “State roots are posted to Ethereum L1.” 5. “Inputs for the state transition function are posted to Ethereum L1.” 6. “A source-available node exists that can recreate the state from Ethereum L1 data. Please note that the L2BEAT team has not verified the validity of the node source code.” - **Stage 1 — 8 requirements met**, including its principle, as quoted from the checklist: 1. “Users are able to exit without the help of the permissioned operators.” 2. “In case of an unwanted upgrade by actors more centralized than a Security Council, users have at least 7d to exit.” 3. “The Security Council is properly set up.” 4. “The proof system meets the minimum trusted setup requirements defined in the L2BEAT trusted setup assessment framework.” 5. “Prover source code is published.” 6. “Onchain verifiers' smart contracts can be independently regenerated from the verifier source code.” 7. “The sources of all programs used are public and program hashes can be independently regenerated.” 8. Principle: “Compromising ≥75% of the Security Council is the only way (other than bugs) for a rollup to indefinitely block an L2→L1 message (e.g. a withdrawal) or push an invalid L2→L1 message (e.g. an invalid withdrawal) with a <7d exit window.” - **Stage 2 — 1 met, 2 unmet**, as quoted from the checklist: met, “Fraud proof submission is open to everyone.” Unmet, “Upgrades unrelated to onchain provable bugs provide less than 30d to exit.” Unmet, “The Security Council's actions are not confined to onchain provable bugs.” - The current Base stage section displays **no “under review” or warning banner**. Its standing note says stages are an opinionated maturity assessment and “do not reflect project security.” ## 2. Proof system - L2BEAT's **State validation** risk value is **“Fraud proofs (1R, ZK)”**; the page explains single-round fraud proofs with a ZK proof, while its category remains **Optimistic Rollup**. - Proofs are **live**: the Stage 0 checklist marks a complete and functional proof system deployed. L2BEAT says state-root proposals call `DisputeGameFactory.create` for the `AggregateVerifier` game type, post a **0.05 ETH** bond, and include an initial **TEE attestation or ZK proof**. - Proposal and challenge access: L2BEAT's **Proposer failure** value is **“Self propose”** and says anyone can propose new roots; any party with a valid ZK proof of an incorrect intermediate root may call `AggregateVerifier.challenge`. The Stage 2 checklist marks **“Fraud proof submission is open to everyone.”** - The **TEE arm is permissioned**: `Base Coordinator Multisig` can add or remove allowlisted proposers and register or deregister TEE enclave signers through `TEEProverRegistry`; the Manager EOA can register or deregister enclave signers. L2BEAT describes the ZK challenge route as open to any party producing a valid proof. - Resolution/finality window: **5 days with a single proof; 1 day if both proof arms commit**. A successful ZK challenge contradicts a TEE-only proposal and resolves `CHALLENGER_WINS` if it stands until the window closes. ## 3. Exit window and upgrades - L2BEAT's **Exit window** risk value is **“None.”** Its explanation: “There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable. Upgrades need to be approved by 2 parties: the Base Coordinator Multisig and the Base Security Council.” - Risk summary: “Funds can be stolen if a contract receives a malicious code upgrade.” L2BEAT says the two parties above approve upgrades and **there is no delay**. - **Base Governance Multisig (2/2)** controls `ProxyAdmin`; its two members are **Base Coordinator Multisig (3/6)** and **Base Security Council (8/11)**. Both must approve upgrades, with **no timelock or Safe delay module**; the Council cannot be bypassed for `ProxyAdmin` upgrades. L2BEAT counts the nested arrangement as **9 of 12 entities (75%)**, while the Council Safe alone is **8/11 (72.7%)**. - The Governance Multisig can upgrade, **with no delay**, the `ProxyAdmin`-controlled contracts listed in Permissions: `L2CrossDomainMessenger`, `L2StandardBridge`, `SequencerFeeVault`, `OptimismMintableERC20Factory`, `L1BlockNumber`, `L2ERC721Bridge`, `L1Block`, `L2ToL1MessagePasser`, `OptimismMintableERC721Factory`, `ProxyAdmin`, `BaseFeeVault`, `L1FeeVault`, `SchemaRegistry`, `EAS`, `TEEProverRegistry`, `DelayedWETH`, `L1StandardBridge`, `DisputeGameFactory`, `OptimismPortal2`, `L1ERC721Bridge`, `SystemConfig`, `ProtocolVersions`, `L1CrossDomainMessenger`, `AnchorStateRegistry`, and `SuperchainConfig`. - Beyond code upgrades, the Governance Multisig can set game implementations and bonds, pause or unpause withdrawals as Guardian, blacklist dispute games, change the respected game type, retire in-flight games, and add or freeze SP1 verifier routes. The Coordinator Multisig alone can change the TEE proposer/signer allowlist and `CertManager`; it **cannot** execute `ProxyAdmin` upgrades alone. - **Base Multisig 1 (3/12)** owns `SystemConfig` and can change its sequencer/batch submitter and gas settings; as Incident Responder it can pause withdrawals for up to **3 months and 1 day**, but cannot unpause or extend them. This is a pause/configuration power, **not** a separate `ProxyAdmin` upgrade path. - L2BEAT lists one separate upgrade actor on Base L2: **EOA 2 can upgrade `FeeDisburser` with no delay**. ## 4. Data availability - L2BEAT's **Data availability** risk value is **“Onchain”**: “All of the data needed for proof construction is published on Ethereum L1.” - The DA section says all data required for proofs is published onchain as **Ethereum blobs or calldata**; the page's badge is **“Ethereum with blobs”** and its milestones say Base started using blobs on **2024-03-14**. L2BEAT names **Ethereum** as the current DA layer. - **DAC/threshold: NOT FOUND**; the L2BEAT DA and Permissions sections identify Ethereum onchain DA and list no DAC. ## 5. Sequencer and forced inclusion - L2BEAT says **Base uses a single centralized sequencer** for fast confirmations; its sequencing spec sheet describes **“Centralized 5-instance Raft HA.”** `Base Multisig 1` can update the batch submitter/sequencer address in `SystemConfig`. - L2BEAT's **Sequencer failure** value is **“Self sequence.”** Users can bypass the sequencer by sending a transaction to Ethereum L1's `OptimismPortal`; Base nodes derive the deposit and include it after at most one sequencing window. The stated inclusion delay is **up to 12 hours / 3,600 L1 blocks**. - L2BEAT's **Proposer failure** value is **“Self propose”**: anyone can propose new roots to the L1 bridge. Its Withdrawals section also describes direct L1 forced messaging if normal L2→L1 messaging is censored. ## Stage history since 2026-04-27 - **No Stage change found between 2026-04-27 and 2026-10-27**. The current project page displays **Stage 1**. Its Milestones include **“Base achieves Stage 1” on 2025-04-29**; the window's **2026-05-26 “Base Azul: multi-proof”** milestone describes a proof-system change, not a new Stage designation. - Git check: the last `base.ts` revision before the window, committed **2026-03-10**, has the Stage 0 requirements true, the Stage 1 principle/core requirements true, and two Stage 2 requirements false; the then-pending extra Stage 1 checks had an **2026-08-17** deadline. Thus its evaluated designation at the window's start was Stage 1. - I checked the **17 commits** to `packages/config/src/projects/base/base.ts` in the window. The **2026-05-06** commit renamed the stage helper; **2026-06-05** commits marked prover source, program-hash and verifier reproducibility checks, and **2026-07-28** marked the trusted-setup check met. None changes the two false Stage 2 fields; the current config still has `proofSystemOverriddenOnlyInCaseOfABug: false` and `delayWith30DExitWindow: false`. No commit URL for a stage change exists in the checked history. ## Not found - **NOT FOUND:** The named legal operator of the centralized sequencer, beyond L2BEAT's “Base uses” description and the `Base Multisig 1` configuration authority. I checked Operator, Sequencing and Permissions. - **NOT FOUND:** The current share of transaction data sent via blobs versus calldata. I checked Data availability, Data posted and the blob milestone; L2BEAT says “blobs or calldata” without a split. - **NOT FOUND:** Whether access to an external SP1 proving service itself is permissionless. The page establishes permissionless fraud-proof submission/ZK challenges, but does not specify service admission. I checked State validation, Stage and Permissions. - **NOT FOUND:** Newest main node or prover software release and its release date on L2BEAT; State derivation names `op-node` and `op-geth`, and Stage links prover source, but neither section gives a latest tagged release/date. I checked State derivation and Stage only, under this item's L2BEAT-only source limit.