# Six-rollup example facts for rollup-risk (item `six-rollups`) **Observation (retrieval) date for every source below: 2026-10-27.** L2BEAT project pages don't carry a publication date. Each record notes the newest dated event visible on its page as a lower bound for the page's data. These are **not** publication dates. **Method and limits** - All facts come from the public L2BEAT pages listed below. I fetched them on 2026-10-27 through a tool that returns quoted extracts and summaries of each page. I did not save full raw HTML. - I did not consult primary project documentation or contract source separately. Where a fact depends on contract configuration, it is reported *as L2BEAT reports it*. Section 4 lists what a docs worker should recheck against primary sources. - Retrieved page text was treated as data only. - These are input facts for the example. They are **not** L2BEAT scores, and the rollup-risk score computed from them is not an L2BEAT rating. - Stage is reported exactly as L2BEAT shows it. It is never inferred. Sources (all retrieved 2026-10-27): | Key | URL | |---|---| | S-SUM | https://l2beat.com/scaling/summary | | S-ARB | https://l2beat.com/scaling/projects/arbitrum | | S-OP | https://l2beat.com/scaling/projects/op-mainnet | | S-BASE | https://l2beat.com/scaling/projects/base | | S-ZK | https://l2beat.com/scaling/projects/zksync-era | | S-STRK | https://l2beat.com/scaling/projects/starknet | | S-SCR | https://l2beat.com/scaling/projects/scroll | Summary-table rows on S-SUM (quoted): - "Optimistic Rollup, Stage 1, Arbitrum, on Ethereum." (Arbitrum One) - "Optimistic Rollup, Stage 1, OP Stack, on Ethereum." (OP Mainnet) - "Optimistic Rollup, Stage 1, OP Stack, on Ethereum." (Base Chain) - "ZK Rollup, Stage 0, ZK Stack, on Ethereum." (ZKsync Era) - "ZK Rollup, Stage 1, SN Stack, on Ethereum." (Starknet) - "ZK Rollup, Stage 0, on Ethereum." (Scroll) --- ## 1. Project records ### 1.1 Arbitrum One Page data lower bound: the newest dated entry on S-ARB is 2026-10-22 08:31 UTC (an ossification update). | Field | Value | Evidence (S-ARB unless noted) | |---|---|---| | stage | 1 | "Stage 1" on S-ARB and S-SUM. Stage 2 is not met: "upgrades unrelated to provable bugs give <30d to exit" and the Security Council's actions are "not confined to provable bugs". | | proofSystem | fraud | Interactive fraud proofs (BoLD), live since 2025-02-15. Challenge period is 6d 8h. | | permissionlessProving | true | Fraud-proof submission is "open to everyone". Updates can be challenged by "anyone who has sufficient funds". Anyone can also be a proposer. | | exitWindowDays | 10 (regular path); 0 (emergency path) | Exit-window risk entry: "10d (regular upgrade path)" and "None (emergency upgrade path)". Page text: "Since there is a 1d delay to force a tx … users have 10d to exit." | | upgrades | securityCouncil, 9/12 | Governance table: Security Council of "12 members across two 6-seat cohorts", threshold "9/12". The SC can act in an emergency with no delay. Regular upgrades go through the DAO plus the L2 8d timelock, the L1 challenge period and the L1 3d timelock. | | dataAvailability | ethereumBlobs | "All of the data needed for proof construction is published on Ethereum L1". Blobs have been used since 2024-03-14; calldata was used before that. | | forceInclusion | true | "users can force transactions to be included in the project's chain by sending them to L1 … There can be up to a 1d delay on this operation." | Caveats: - **The exit-window figures on S-ARB conflict.** The risk entry gives 10d. The governance table gives "~17.4d non-emergency". The overall code-upgrade delay is cited as 17d 8h. I use the risk-entry value of 10. - The emergency path gives users no exit window. ### 1.2 OP Mainnet Page data lower bound: the newest dated entry on S-OP is 2026-09-24 16:51 UTC. | Field | Value | Evidence (S-OP) | |---|---|---| | stage | 1 | "Stage 1" on S-OP and S-SUM. Stage 2 issues: "Upgrades unrelated to onchain provable bugs provide less than 30d to exit" and "The Security Council's actions are not confined to onchain provable bugs." | | proofSystem | fraud | Interactive fraud proofs, live. "A complete and functional proof system is deployed" is marked met. Historical note: fraud proofs were disabled for about 26 days in Aug 2024 and re-enabled with Granite on 2024-08-28. | | permissionlessProving | true | "Anyone can be a Proposer" (0.08 ETH bond). Challenges are open to "anyone who has sufficient funds". Fraud-proof submission is listed as open to everyone. | | exitWindowDays | 0 | Exit-window risk entry: "None". Risk text: "There is no delay on regular upgrades." Emergency upgrades are instant (Foundation plus SC, 2/2). | | upgrades | securityCouncil, 10/13 (conservative mapping, see caveat) | The SuperchainProxyAdmin is controlled by a 2/2 multisig of the Optimism Foundation and the Security Council. The Security Council is a Safe at "10/13" (cohorts of 7 + 6; the charter sets a 75% threshold). The SC also holds the Guardian role. The Foundation can pause withdrawals via a Safe module; each pause lasts up to 3 months. | | dataAvailability | ethereumBlobs | Data is published on Ethereum L1 "in the form of cheap blobs or calldata". Blob posting began 2024-03-14. | | forceInclusion | true | Users can force transactions by sending them to L1, with "up to a 12h delay on this operation." | Caveats: - S-OP describes a governance process with a 7-day veto window and Developer Advisory Board (DAB) review. That is off-chain or process-level. The onchain risk entry still says there is no delay and the exit window is "None", so I map 0. - The Stage 1 "≥7d to exit for actors more centralized than an SC" item is marked met because the SC must co-sign every upgrade. That is not a user exit window. - Upgrades need *both* the Foundation and the SC. The schema can only express the SC part. ### 1.3 Base (L2BEAT name: "Base Chain") Page data lower bound: the newest dated events on S-BASE are a 2026-10-09 09:36 UTC upgrade and an anomaly ending 2026-10-09 14:08 UTC. | Field | Value | Evidence (S-BASE) | |---|---|---| | stage | 1 | Header and S-SUM: "Optimistic Rollup, Stage 1". Same two Stage 2 issues as OP Mainnet. | | proofSystem | fraud | State validation: "Fraud proofs (1R, ZK) (5d challenge period)". Since the Azul upgrade (2026-06-03), proposals carry a TEE-attestation arm and an SP1 ZK-proof arm. A game finalizes after 5d with one proof, or after 1d if both arms commit. L2BEAT classifies the chain as an "Optimistic Rollup". | | permissionlessProving | true (with caveat) | Fraud-proof submission is open to everyone (checklist "Met"). Any party with a valid ZK proof can call `AggregateVerifier.challenge`. Quote: "a permissionless ZK proof is needed to finalize the state and exit on L1." A self-proposed state needs a valid ZK proof and a 0.05 ETH bond. **However**, the TEE prover allowlist is permissioned: the Base Coordinator Multisig can "add or remove allowlisted proposers". | | exitWindowDays | 0 | Exit-window risk entry: "None (sentiment: bad)". Quote: "There is no delay on upgrades". Contracts are instantly upgradable via the Base Governance Multisig. | | upgrades | securityCouncil, 8/11 (conservative mapping, see caveat) | ProxyAdmin owner: "Base Governance Multisig", a 2/2 whose members are the Base Coordinator Multisig ("3/6 threshold", Coinbase) and the Base Security Council ("A Multisig with 8/11 threshold"). The Stage 1 item "The Security Council is properly set up" is Met. | | dataAvailability | ethereumBlobs | "All of the data needed for proof construction is published on Ethereum L1". Blobs have been used since 2024-03-14. | | forceInclusion | true | Users can force transactions via L1, with "up to a 12h delay on this operation." | Caveats: - **The Stage 1 checklist marks "users have at least 7d to exit" as Met, but the Exit-window risk entry says None.** As with OP, this is because the SC must co-sign. The user exit window is 0. - S-BASE describes the Council as "8/11". It also says that, when nested with the Coordinator, it counts as about 9 of 12 entities (75%). The schema value I use is the Council's own Safe threshold, 8/11. - S-BASE says the Council's charter is "None" and that it has no removal procedure. - "Base Multisig 1" (3/12, per S-BASE) can pause withdrawals for up to 3 months. It also controls `SystemConfig` and the single sequencer. - Proof is hybrid TEE plus ZK. Mapping it to `fraud` follows L2BEAT's classification; it is not a validity rollup. ### 1.4 ZKsync Era Page data lower bound: the newest dated item on S-ZK is a 2026-10-08 update (anomaly ending 13:14 UTC, execution delay raised to 1 day). | Field | Value | Evidence (S-ZK) | |---|---|---| | stage | 0 | "ZKsync Era is a Stage 0 ZK Rollup." The page lists 3 Stage 1 issues and 1 Stage 2 issue. | | proofSystem | validity | "STARKs and SNARKs are zero knowledge proofs". Proofs are being verified onchain; the current verifier has been "currently used" since 2026-04-28. Execution delay is now 1d. | | permissionlessProving | false | "Only the whitelisted proposers can publish state roots on L1". Validators are whitelisted behind the ValidatorTimelock; the Era multisig validator is at a 3/8 threshold since 2026-05-04. | | exitWindowDays | 5 (regular path); 0 (emergency path) | Risk summary: "5d (regular upgrade path)" and "None (emergency upgrade path)". Code-upgrade delay is "5d - 9d" normally, with no delay via the EmergencyUpgradeBoard. | | upgrades | securityCouncil, 6/8 (conservative mapping, see caveat) | Security Council: "A Multisig with 6/8 threshold" (upgrade-approval threshold 4). Emergency: "allowing a 3/3 of SecurityCouncil, ZK Foundation Multisig and Guardians" to upgrade "with no delay". Guardians are 5/8 and the ZK Foundation Multisig is 3/6. The Matter Labs Multisig (4/7) can upgrade some peripheral contracts (EraMultisigValidator, ServerNotifier) with no delay. | | dataAvailability | ethereumBlobs | State diffs are published onchain on Ethereum ("Onchain (SD)") "in the form of cheap blobs or calldata". Blobs have been used since 2024-03-13. | | forceInclusion | false | Sequencer failure: "Enqueue via L1". Users can enqueue but "can't force them". Quote: "Right now there is no mechanism that forces L2 Sequencer to include transactions from the queue". Quote: "The operator can implement a TransactionFilterer that censors forced transactions." | Caveats: - **The exit-window figures on S-ZK conflict.** The risk summary gives 5d. The governance section gives "~4 days" when the SC approves promptly. I use 5, the risk-entry value. Recheck this. - Upgrades are normally token-governance proposals that the SC approves; emergency upgrades need all three bodies. The `securityCouncil 6/8` value records only the SC's own Safe threshold. - **Recheck the 6/8 size.** Older public material described the ZKsync SC as 12-member. - An L1 priority queue exists. That is not forced inclusion. Don't conflate it with Arbitrum- or OP-style forced inclusion, or with forced withdrawals. ### 1.5 Starknet Page data lower bound: the newest dated item on S-STRK is an upgrade at 2026-10-14 11:07 UTC. | Field | Value | Evidence (S-STRK) | |---|---|---| | stage | 1 | "Starknet is a Stage 1 ZK Rollup." Two Stage 2 issues are listed. The page says it "does not pass the walkaway test". | | proofSystem | validity | "STARKs are zero knowledge proofs that ensure state correctness". No execution delay. | | permissionlessProving | false | The Operator role "is not permissionless". Quote: "Only the whitelisted proposer can update state roots on L1." | | exitWindowDays | 7 (regular path); 0 (emergency path) | Risk entry: "7d" on the regular path (8d onchain delay minus a 1d censorship-resistance step) and "None" on the emergency path, because the SC can upgrade instantly. | | upgrades | securityCouncil, 9/12 | Security Council: a 9/12 Safe that can upgrade instantly, "intended for emergencies only". Regular upgrades are queued by Starkware Multisig 1 (2/6) in a DelayedExecutor with an 8d delay. | | dataAvailability | ethereumBlobs | State diffs are published onchain "as blob or calldata on every state update". Blobs have been used since 2024-03-13. | | forceInclusion | false | Users "can submit transactions to an L1 map, but can't force them." A 3/12 SC minority can post a state root including stuck transactions, but this process "is not defined" and the council "has no protocol deadline to respond". | Caveats: - **The exit-window figures on S-STRK conflict.** The risk entry gives 7d; the governance table gives 8d. I use 7. - **Starkware Multisig 2 (2/4) can upgrade most *other* bridge escrows instantly.** The SHARP Multisig (2/4) can change the shared verifier with an 8d delay. The core Starknet contract is SC-gated, but the effective controller of assets in non-core bridges is a 2/4 team multisig. The schema cannot express this, so the docs must state it. - The SC-minority escape hatch is conditional and has no deadline. That is why I map forceInclusion false. ### 1.6 Scroll Page data lower bound: the newest dated item on S-SCR is 2026-10-08 10:24 UTC. | Field | Value | Evidence (S-SCR) | |---|---|---| | stage | 0 | "Scroll is a Stage 0 ZK Rollup." S-SCR says it reached Stage 1 in April 2025 and fell to Stage 0 after the Security Council was removed on 2026-06-01. | | proofSystem | validity | ZK validity proofs (OpenVM-based circuits, SNARK-wrapped STARK), "No execution delay". | | permissionlessProving | false (conditional, see caveat) | "Sequencing and proposing are behind a whitelist unless enforcedBatchMode is activated." Also mentions "permissioned batchers and provers". | | exitWindowDays | 0 | "There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable." | | upgrades | multisig | The 9/12 Security Council was replaced on 2026-06-01 by `ScrollAdminMultisig`, "A Multisig with 3/4 threshold" of Scroll team members. Per S-SCR this "does not meet the size or organisational-diversity requirements of a Security Council." A 2/4 emergency multisig (Scroll Multisig 2) can pause, change the whitelist and revert unfinalized batches. | | dataAvailability | ethereumBlobs | "All of the data needed for proof construction is published on Ethereum L1", posted as blobs. | | forceInclusion | true (conditional, see caveat) | Self-sequencing via L1 with "up to a 7d delay". Enforced-batch mode (Euclid upgrade, 2025-04-24) activates if an L1 message or batch stays unfinalized for more than 7 days. | Caveats: - **`ScrollAdminMultisig` can "disable enforced batch mode [via: TimelockSCEmergencyScroll]", which has a 0s minimum delay.** So the forced-inclusion path exists only while the admin chooses not to disable it. - In enforced-batch mode, proposing and proving open to anyone. That is a fallback, not normal operation, so I map permissionlessProving false. - A "Scroll Security Council Minority" multisig (3/12) is still listed. The admin multisig holds the `scMinorityNoDelay` role. --- ## 2. Candidate JSON (schema-compatible) Every field has an evidenced value, so I give a candidate array. Fixed mapping conventions: - `exitWindowDays` is L2BEAT's Exit-window risk value for the **regular** upgrade path. "None" maps to 0. The emergency path is 0 for every project; see section 3. - `upgrades.securityCouncil` threshold and members are the Council's own Safe threshold as L2BEAT lists it. Co-signers (OP Foundation, Coinbase Coordinator, ZKsync Foundation and Guardians) are not representable in the schema. - `dataAvailability` is the observed posting mode. Every project currently posts blobs; each can fall back to calldata. These are not `external`. - Names follow L2BEAT's display names, except that "Base Chain" is shortened to "Base" to match the brief. ```json [ { "name": "Arbitrum One", "stage": 1, "proofSystem": "fraud", "permissionlessProving": true, "exitWindowDays": 10, "upgrades": { "type": "securityCouncil", "threshold": 9, "members": 12 }, "dataAvailability": "ethereumBlobs", "forceInclusion": true }, { "name": "OP Mainnet", "stage": 1, "proofSystem": "fraud", "permissionlessProving": true, "exitWindowDays": 0, "upgrades": { "type": "securityCouncil", "threshold": 10, "members": 13 }, "dataAvailability": "ethereumBlobs", "forceInclusion": true }, { "name": "Base", "stage": 1, "proofSystem": "fraud", "permissionlessProving": true, "exitWindowDays": 0, "upgrades": { "type": "securityCouncil", "threshold": 8, "members": 11 }, "dataAvailability": "ethereumBlobs", "forceInclusion": true }, { "name": "ZKsync Era", "stage": 0, "proofSystem": "validity", "permissionlessProving": false, "exitWindowDays": 5, "upgrades": { "type": "securityCouncil", "threshold": 6, "members": 8 }, "dataAvailability": "ethereumBlobs", "forceInclusion": false }, { "name": "Starknet", "stage": 1, "proofSystem": "validity", "permissionlessProving": false, "exitWindowDays": 7, "upgrades": { "type": "securityCouncil", "threshold": 9, "members": 12 }, "dataAvailability": "ethereumBlobs", "forceInclusion": false }, { "name": "Scroll", "stage": 0, "proofSystem": "validity", "permissionlessProving": false, "exitWindowDays": 0, "upgrades": { "type": "multisig" }, "dataAvailability": "ethereumBlobs", "forceInclusion": true } ] ``` Unresolved fields: none are missing. The values that rest on inconsistent L2BEAT text or on a judgment call are flagged in sections 3 and 4. None is a stand-in. ## 3. Text for `docs/example-sources.md` (dated references and caveats) > The example input (`examples/rollups.json` or equivalent) describes Arbitrum One, OP Mainnet, Base, ZKsync Era, Starknet and Scroll as observed on **L2BEAT on 2026-10-27**: > - https://l2beat.com/scaling/summary > - https://l2beat.com/scaling/projects/arbitrum > - https://l2beat.com/scaling/projects/op-mainnet > - https://l2beat.com/scaling/projects/base > - https://l2beat.com/scaling/projects/zksync-era > - https://l2beat.com/scaling/projects/starknet > - https://l2beat.com/scaling/projects/scroll > > L2BEAT pages are continuously updated and have no publication date. The date above is when we looked. Rollup configurations change through upgrades, so treat the example as a snapshot, not current truth. The rollup-risk score is our own heuristic. It is not an L2BEAT score or rating. Only the `stage` field is copied from L2BEAT. > > Mapping notes: > - `exitWindowDays` is the regular-upgrade-path exit window from L2BEAT's risk section. For every project in the example, an emergency or Security Council path can upgrade with **no** exit window. Arbitrum One, ZKsync Era and Starknet show figures elsewhere on their pages (about 17.4d, about 4d and 8d respectively) that differ from the risk-section value we used (10, 5 and 7). > - An upgrade delay is not the same thing as an exit window. OP Mainnet and Base pass L2BEAT's Stage 1 "7d to exit" check only because their Security Council must co-sign upgrades. Their user exit window is 0. > - `upgrades: securityCouncil` records the Council's own multisig threshold. On OP Mainnet (with the Optimism Foundation), Base (with the Coinbase Coordinator 3/6) and ZKsync Era (with Guardians and the ZK Foundation for emergencies), upgrades also need other co-signers. On Starknet, a 2/4 StarkWare multisig can instantly upgrade most non-core bridge escrows. > - Scroll replaced its Security Council with a 3/4 team multisig on 2026-06-01 and is mapped `multisig`. > - `forceInclusion` means a user can force an L2 transaction in, not merely force a withdrawal or enqueue a message: > - ZKsync Era has an L1 priority queue but no mechanism forcing the sequencer to process it. It is mapped false. > - Starknet relies on a deadline-free Security Council minority. It is mapped false. > - Scroll's 7-day enforced-batch mode can be disabled instantly by its admin multisig. It is mapped true, conditionally. > - Every project posts data to Ethereum as blobs, with calldata as a fallback. None uses an external DA layer. > - `proofSystem` for Base is `fraud`: L2BEAT lists "Fraud proofs (1R, ZK)", with a hybrid TEE plus ZK design since June 2026. > - `permissionlessProving` for Base is true because L2BEAT says a "permissionless ZK proof" suffices. Its TEE prover allowlist is permissioned. ## 4. Facts a docs worker must recheck or label carefully 1. **Exit-window inconsistencies on L2BEAT.** - Arbitrum: 10d in the risk entry vs ~17.4d in the governance table. - ZKsync Era: 5d vs ~4d. - Starknet: 7d vs 8d. - Base: the Stage-1 "≥7d to exit" item is Met, yet the Exit window is "None". Re-open each page before publishing. If the risk-section values change, update the JSON and README output together. 2. **ZKsync Security Council size, 6/8.** This comes from L2BEAT's permissions list. Older sources said 12 members. Verify on L2BEAT and in ZKsync governance docs (docs.zknation.io) or the onchain Safe. 3. **Base Security Council, 8/11.** Verify the Safe. L2BEAT also shows a "≈9 of 12 entities" nested framing, so don't mix the two. 4. **OP Mainnet SC 10/13.** L2BEAT lists this; the charter states a 75% threshold. Verify against Optimism governance docs. 5. **Scroll Stage 0 and the 2026-06-01 SC removal.** This is a recent change. Confirm it on L2BEAT and in Scroll governance announcements. Label the `multisig` mapping and the conditional `forceInclusion: true`. 6. **Base proof design** (Azul upgrade 2026-06-03, TEE plus SP1 ZK; 5d window shortened from 7d on 2026-06-25). This is recent. Recheck the classification and permissionless status. 7. **Arbitrum DA.** L2BEAT says blobs since 2024-03-14. Label it "blobs (calldata fallback)", like the others. 8. **Primary documentation was not separately fetched** in this item. Every fact above is sourced from L2BEAT as observed on 2026-10-27. The page extracts were obtained through a summarizing fetch tool. Exact quotations should be spot-checked against the live page before they appear verbatim in the docs. 9. Do not describe the example's numbers as "L2BEAT scores". Do not imply that `exitWindowDays` holds against emergency upgrades; it holds for none of the six.