# Base: facts from the project's own documentation (second source behind L2BEAT)

Sources: docs.base.org only, fetched 2026-10-27 (pages fetched as `.md` and from https://docs.base.org/llms-full.txt). No L2BEAT, news or memory used.

## 2. Proof system

- **Type: multi-proof (TEE + ZK) since the Azul upgrade. This replaced the earlier optimistic, interactive fault-proof system.** The docs say: "Azul introduces a multi-proof system for the L2 checkpoints that secure withdrawals to L1… Each proposal… is submitted to `AggregateVerifier`, an L1 dispute game that can verify one or two proofs for the same proposal." Source: https://docs.base.org/upgrades/azul/proofs
- About the earlier system they say: "Base's current fault-proof system is optimistic and interactive: a proposal resolves unless someone challenges it… Azul replaces that model with a multi-proof design built around TEE and ZK provers. TEE proofs support the common path, ZK proofs provide a permissionless backstop." Source: https://docs.base.org/upgrades/azul/proofs
- **Provers:**
  - TEE provers run on AWS Nitro Enclaves: "the enclave re-executes the requested L2 block range… and signs the resulting checkpoint outputs." Source: https://docs.base.org/upgrades/azul/proofs
  - The ZK prover "uses SP1 programs to produce permissionless proofs." Proofs are verified onchain through the Succinct SP1 verifier gateway (`ZKVerifier`), with a Groth16 SNARK as the final onchain proof. Sources: https://docs.base.org/specifications/base-protocol/proofs/zk-prover and https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
- **Who can propose: whitelisted on the TEE path.** "The TEE path is permissioned… The ZK path is permissionless and can override an invalid TEE-backed claim." Source: https://docs.base.org/upgrades/azul/proofs
  - A TEE proof is valid only when "the proposer is allowlisted in `TEEProverRegistry`" and the signer is registered there. "The owner can set proposer addresses." Source: https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
  - A proposer creates a game "providing an initial TEE or ZK proof". The finality table lists "ZK only… Permissionless path without TEE reliance". Sources: https://docs.base.org/specifications/base-protocol/proofs/proof-contracts and https://docs.base.org/upgrades/azul/proofs
  - "The production proposer is controlled by its configured L1 transaction signer." Source: https://docs.base.org/specifications/base-protocol/proofs/proposer
- **Who can challenge: anyone, with a ZK proof.** "Anyone can run a challenger… The permissionless dispute path is a ZK proof challenge. Base will run a challenger as a security backstop, and Base's challenger also has access to a TEE nullification path." Source: https://docs.base.org/upgrades/azul/proofs
  - Also: "The challenger is permissionless in the ZK path: any operator with access to canonical L1 and L2 RPCs, a ZK proving service, and an L1 transaction signer can run it." Source: https://docs.base.org/specifications/base-protocol/proofs/challenger
  - `resolve()` and `closeGame()` can be called by anyone. Source: https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
- **Centralised overrides:** "The `SystemConfig.guardian()` can: set the respected game type; update the retirement timestamp…; blacklist individual games." Source: https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
  - Elsewhere the docs say: "Centralized guardrails reduce that risk today, but that is not a long-term model for Stage 2." Source: https://docs.base.org/upgrades/azul/proofs
- **Challenge period / finality:**
  - Current values: a single-proof game waits 5 days (`SLOW_FINALIZATION_DELAY`, "5 days since Beryl"). A game with both TEE and ZK proofs waits 1 day (`FAST_FINALIZATION_DELAY`). "A challenge with a ZK proof sets `expectedResolution` to 7 days from the challenge." Source: https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
  - Beryl (mainnet June 25, 2026) cut the single-proof window from 7 to 5 days; the dual-proof window stays 1 day. Sources: https://docs.base.org/upgrades/beryl/reducing-canonical-withdrawal-delay and https://docs.base.org/upgrades/overview
  - The same figures appear at https://docs.base.org/specifications/transactions/transaction-finality and https://docs.base.org/specifications/base-protocol/bridging/withdrawals
- **Stale wording to note:** the Azul spec page still gives 7 days for the TEE-only and ZK-only paths, i.e. the pre-Beryl figure. Source: https://docs.base.org/upgrades/azul/proofs
- **Mainnet dates:**
  - Azul (multi-proof) went live on mainnet May 28, 2026 (Sepolia April 20, 2026). Sources: https://docs.base.org/upgrades/azul/overview and https://docs.base.org/upgrades/overview
  - Earlier: "Base launched permissionless fault proofs… in October 2024." Source: https://docs.base.org/specifications/security/security-council-for-base
- **Contradiction:** the Configuration page still describes "Challenger | Interacts with permissioned dispute games" and "Proposer | Creates permissioned dispute games on L1". The respected game type is given as "Aggregate verifier (`621`)". Source: https://docs.base.org/specifications/reference/configuration

## 3. Exit window and upgrades

- **Upgrade authority:** "These upgrades are governed by a 2-of-2 multisig. Both parties must independently approve an upgrade before it can take effect":
  - **CB Signers:** "a 3-of-6 multisig operated by Coinbase". It counts as a single signer for the overall quorum.
  - **Security Council:** "an 8-of-11 multisig composed of 11 independent entities and individuals."
  - Overall: "12 participants in total, and any upgrade requires the approval of 9 of them (the CB Signers plus at least 8 Security Council members)."
  - Source: https://docs.base.org/specifications/security/security-council-for-base
- **When the council took over:** "decentralized control of contract upgrades via a Security Council in April 2025". The roster is given "as of February 2026", with cohort terms ending October 2026 and January 2027. Source: https://docs.base.org/specifications/security/security-council-for-base
- **Admin addresses (Gnosis Safes):**
  - Base Security Council `0x20AcF55A3DCfe07fC4cecaCFa1628F788EC8A4Dd`
  - CB Multisig `0x9855054731540A48b28990B63DcF4f33d8AE46A1`
  - Proxy Admin Owner (L1) `0x7bB41C3008B3f03FE483B28b8DB90e19Cf07595c` (also listed as Guardian)
  - SystemConfig owner / Incident Multisig `0x14536667Cd30e52C0b458BaACcB9faDA7046E056`
  - L1 ProxyAdmin `0x0475cBCAebd9CE8AfA5025828d5b98DFb67E059E`
  - Source: https://docs.base.org/specifications/reference/base-contracts
- **Contradiction:** the Configuration page gives a different "L1 ProxyAdmin Owner": `0x5a0Aae59D09fccBdDb6C6CcEB07B7279367C3d2A`. Source: https://docs.base.org/specifications/reference/configuration
- **Other powers:**
  - The Guardian "Pauses L1 withdrawals, blacklists dispute games, sets respected game type". Source: https://docs.base.org/specifications/reference/configuration
  - The `DelayedWETH` proxy admin owner can `recover` ETH and `hold` WETH. Source: https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
- **Timelock / exit window:** NOT FOUND. No page states an upgrade timelock in days, or that users get a window to exit before an upgrade takes effect. The only "timelock" hit in llms-full.txt is unrelated (a devnet note).

## 4. Data availability

- **Ethereum, mainly blobs (EIP-4844):** "As of the Cancun L1 upgrade, the primary data availability mechanism is EIP-4844 blob transactions. Each blob carries one frame of compressed channel data." Source: https://docs.base.org/specifications/base-protocol/batcher
- **Blobs or calldata, no Alt-DA:** Data Availability Type is "Whether the batcher posts data as blobs or calldata. Ethereum (Blobs or Calldata); Alt-DA not supported." Batch submission frequency is "≤ 1,800 L1 blocks (6 hours…)". Source: https://docs.base.org/specifications/reference/configuration
- **Blob support date:** Ecotone (EIP-4844 blob support) went live on Base Mainnet March 14, 2024. Source: https://docs.base.org/upgrades/overview
- **Batch posting time:** "After roughly 2 minutes, a Base batch containing the transaction has been posted to Ethereum." Source: https://docs.base.org/specifications/transactions/transaction-finality

## 5. Sequencer and forced inclusion

- **Sequencer: centralised.** "Base currently operates a single active sequencer. The sequencer runs as a high-availability cluster in which leadership transfers to a follower if the current leader stops producing blocks." Source: https://docs.base.org/specifications/security/reliability-and-liveness
  - The docs do not name the operator on this page. Elsewhere they call Base "an Ethereum L2 built by Coinbase". Source: https://docs.base.org/llms.txt
- **Forced inclusion:** "If the sequencer censors your transactions or stops producing blocks, you can still get a transaction onto Base by sending it as a deposit through the `OptimismPortal` contract on Ethereum… Each L1 block defines the deposits that must be included in the first L2 block of its sequencing epoch. A block that omits them is invalid." Source: https://docs.base.org/specifications/security/reliability-and-liveness
  - The deposit feed contract on L1 is "called `OptimismPortal`" (mainnet `0x49048044D57e1C92A77f79988d21Fa8fAF74E97e`). Sources: https://docs.base.org/specifications/base-protocol/bridging/deposits and https://docs.base.org/specifications/reference/base-contracts
  - The protocol overview diagram labels the user's call `depositTransaction`. Source: https://docs.base.org/specifications/base-protocol/overview
- **Delay:** "nodes wait one sequencing window and then derive the missing L2 blocks themselves, including the pending deposits. On Base the sequencing window is 3,600 L1 blocks, about 12 hours." Source: https://docs.base.org/specifications/security/reliability-and-liveness
  - The same figure is in the configuration reference ("Sequencing Window Size… 3,600 L1 blocks (12 hours…)"). Source: https://docs.base.org/specifications/reference/configuration
- **Normal deposit time:** deposits "typically get included within 3 minutes by the Base sequencer." Source: https://docs.base.org/specifications/transactions/transaction-finality
- **Open-source sequencer software:** base-consensus, base-reth-node and base-builder (in github.com/base/base), plus op-conductor and rollup-boost. Source: https://docs.base.org/specifications/security/reliability-and-liveness

## 1. Stage

- **Stage 1 claim:** "Base launched permissionless fault proofs in October 2024, decentralized control of contract upgrades via a Security Council in April 2025, and has now reached Stage 1 Decentralization." Source: https://docs.base.org/specifications/security/security-council-for-base
- **Stage 1 council requirements the docs cite:** "at least 8 participants; a ≥75% quorum; a quorum-blocking group outside the main rollup operator (Base)". Source: https://docs.base.org/specifications/security/security-council-for-base
- **Roadmap:**
  - "the role of the Security Council will be progressively minimized, paving the way for even more trustless infrastructure beyond Stage 1—Stage 2". Source: https://docs.base.org/specifications/security/security-council-for-base
  - The Azul upgrade is described as "increasing security and decentralization". The old fault-proof model's "centralized guardrails… is not a long-term model for Stage 2 decentralization." Sources: https://docs.base.org/upgrades/azul/overview and https://docs.base.org/upgrades/azul/proofs
- **Undated:** the page does not date the Stage 1 claim. The docs also do not say whether the stage was reassessed after Azul or Beryl.

## Not found

- **Upgrade timelock** (delay in days) and any **user exit window** before upgrades take effect.
  - Tried: https://docs.base.org/specifications/security/security-council-for-base, https://docs.base.org/specifications/reference/configuration, https://docs.base.org/specifications/reference/base-contracts, and a full-text search of https://docs.base.org/llms-full.txt for "timelock", "exit window" and "upgrade delay".
- **Guardian / Proxy Admin Owner thresholds:** the signer thresholds of these Safes, and of the SystemConfig owner / Incident Multisig, are not given (only addresses). The docs do give 3-of-6 for CB Signers and 8-of-11 for the Security Council.
- **Which L1 ProxyAdmin Owner address is current:** the two pages conflict (see section 3).
- **Whether a ZK-only proposal can be created by any address:** the docs call the ZK path "permissionless" but do not explicitly state that game creation with an initial ZK proof bypasses the proposer allowlist. https://docs.base.org/specifications/base-protocol/proofs/proof-contracts
- **Who operates the sequencer:** the docs do not explicitly name the operator, and do not say whether non-Base sequencers are planned.
- **Newest node/prover release and date:** this was not part of this item's brief and was not checked.
- **Base-run pages that were cited in the docs but not opened:** base.mirror.xyz and blog.base.dev.