Blockchain Protocol Security Audit for Rollups and Sidechains

Summary: Decision‑makers are moving critical value to rollups and sidechains, but their security hinges on nuanced details—proof systems, data availability, forced‑inclusion paths, upgrade powers, and MEV policy. This guide lays out an up‑to‑date, practical audit playbook with concrete checks, incidents, and emerging best practices you can apply before launch or migration.

Why this matters now

In 2024–2025, Ethereum rollups matured fast: EIP‑4844 cut L2 DA costs, Optimism shipped permissionless fault proofs, Arbitrum solidified Stage‑1 guarantees, and alt‑DA options (Celestia, EigenDA, Avail) went live in production or mainnet‑beta. Those changes shift your risk surface in real ways—fees, liveness, exits, censorship resistance, and upgrade pathways. If you’re evaluating a rollup or sidechain, a protocol‑level security audit must go beyond “smart contracts are audited” and prove the system’s end‑to‑end safety under stress, including governance and operations. (blog.ethereum.org)

---

1) Snapshot of the landscape (as of December 15, 2025)

• EIP‑4844 (Dencun, activated March 13, 2024) introduced blobs and a separate data‑gas market. Empirical analyses show rollups’ total fees dropped ~71% with price per MiB down ~82%, though blob demand spikes can still make costs volatile; cost risk management is now part of L2 operations. (blog.ethereum.org)
• OP Stack: governance‑approved, permissionless fault proofs are live on OP Mainnet; the stack targets Stage 1+ and adds prover diversity (Cannon in Go, Kona in Rust). Base documents a 7‑day withdrawal challenge period and explains finality semantics for decision‑makers. (blog.oplabs.co)
• Arbitrum One is assessed Stage 1 on L2BEAT with a 10‑day exit window (because of combined delays). Arbitrum’s BoLD dispute design strengthens censorship‑resistance guarantees and introduces configurable “Delay Buffer” to shorten force‑inclusion during sustained censorship/outages. (l2beat.com)
• Alt‑DA choices are real: Celestia (DAS with 2D Reed‑Solomon, pruning windows), EigenDA (erasure coding + KZG, stake‑weighted quorums), and Avail (KZG + DAS with app‑IDs/light clients). Each brings different trust and ops assumptions you must audit explicitly. (docs.celestia.org)

---

2) Audit scope that actually catches rollup and sidechain failures

Below is the protocol‑level checklist 7Block Labs uses in pre‑launch and migration audits for rollups (OP Stack, Arbitrum, zk stacks) and Ethereum‑adjacent sidechains (e.g., Polygon PoS) and L3s.

2.1 Settlement, upgrades, and emergency powers

• Identify all upgrade authorities and their thresholds (e.g., Optimism Security Council ≥75% threshold; Arbitrum Security Council 9/12; Polygon Protocol Council 7/13 draft). Map which contracts each can touch and the timelocks they must respect. Require proofs that Stage‑1 rules (≥7‑day exits; ≥75% SC compromise needed to block/forge L2→L1 messages) are enforced in deployed configs. (gov.optimism.io)
• Verify “emergency state” semantics: What functions halt? Who can trigger? Polygon zkEVM’s emergency mode can be activated by owner/SC or by anyone upon non‑deterministic state proof, pausing sequencing/bridging; that’s protective but creates operator trust during the pause—capture it explicitly in your risk memo. (docs.polygon.technology)
• Document exit windows end‑to‑end (contract timelocks + challenge periods + batching cadence) and demonstrate users can get assets out without trusted parties if the team disappears. L2BEAT’s 2025 framework clarifies Stage‑1 and Stage‑2 expectations—use it as an external benchmark in your report. (l2beat.com)

Deliverables you should demand:

• A machine‑readable map of privileged roles, timelocks, and callable selectors.
• A rehearsal runbook for emergency upgrades with timestamps matching on‑chain events.

2.2 Proof systems, from “training wheels” to prod

• Optimistic rollups: Confirm fault proofs are permissionless in production, not just testnets; for OP Stack, cite the governance approval and mainnet activation. Check challenger incentives and griefing caps. Validate multi‑implementation diversity (Kona + Cannon) and block‑gas limits compatible with proving. (blog.oplabs.co)
• Arbitrum: Note that Arbitrum One is Stage‑1 per L2BEAT; review BoLD parameters (e.g., Delay Buffer, inclusion windows) and ensure your chain (Orbit/L3) inherits sane defaults. (l2beat.com)
• ZK rollups: Probe the prover pipeline; ZKsync’s Boojum and the 2025 Atlas/Airbender claims need sizing for your throughput and hardware plan. Capture fallback behavior if provers stall (dummy executors, emergency modes). (docs.zksync.io)

What to test:

• Adversarial disputes and long bisection trees; watchdog challengers under DoS.
• “Prover diversity” drills: kill the primary prover; ensure secondary pipeline or alternative implementation can finalize within SLA.

2.3 Data availability (DA) assumptions and cost risk

• Ethereum blobs (EIP‑4844): Fees are near‑zero until demand nears target; then the data‑gas price grows exponentially within hours. Build alerts and budget buffers for blob price spikes, and implement fallback to calldata or alt‑DA—exercise this in staging. (ethresear.ch)
• Celestia: DAS with 2D Reed‑Solomon and light‑client sampling; note the 30‑day sampling/pruning window (CIP‑4). If your business needs >30‑day reconstructability from light nodes, plan archival nodes and retrieval SLAs. (docs.celestia.org)
• EigenDA: Erasure coding + KZG commitments with stake‑weighted quorum attestations; understand coding‑rate γ and safety/liveness thresholds; record which quorums you use and the slashing model backing them. (docs.eigencloud.xyz)
• Avail: KZG + DAS with app‑IDs so clients fetch only their namespace. Audit the light‑client integration and relayer trust model if you’re bridging app‑chain state to EVM. (docs.availproject.org)

2.4 Sequencer, liveness, and forced inclusion

• OP Stack: Validate forced‑transaction (“deposit to OptimismPortal”) behavior across downtime envelopes—30 minutes max drift, up to 12‑hour sequencing window; show deposits land deterministically and can trigger withdrawals without sequencer cooperation. (docs.optimism.io)
• Arbitrum: Verify delayed inbox/force‑inclusion parameters (default ~24 hours, 5760 L1 blocks) and SDK wiring. Document the effect of customized parameters on censorship resistance. (docs.arbitrum.io)
• Incident‑informed SLOs: OP Mainnet has experienced multiple “unsafe head stalls” tied to L1 node or blob availability issues; Base has documented delayed‑transaction and missed‑block incidents. Require real SLOs, alerting, and staged failovers proved against these classes of faults. (status.optimism.io)

2.5 Bridges and token escrows

• Separate messaging security from token escrow security. L2BEAT’s 2025 updates emphasize Stage assessments should focus on the messaging bridge while escrows may have different guarantees; reflect this in your inventory and user disclosures. (forum.l2beat.com)
• For “fast withdrawals” or committee‑based exits (e.g., AnyTrust / Orbit options), ensure users can still fall back to canonical, challenge‑secured withdrawals during committee failures. (docs.arbitrum.io)

2.6 MEV, ordering policy, and preconfirmations

• Arbitrum Timeboost lets chains capture some MEV and dampen latency games—it materially changes ordering incentives; review alpha‑stage config vs. your DeFi footprint. (docs.arbitrum.io)
• OP Stack Flashblocks provides sub‑second preconfirmations; audit equivocation protections and UX disclosures when preconfirmations can be rescinded. (specs.optimism.io)
• Shared/Decentralized sequencers: Espresso offers BFT confirmations and prevents sequencer equivocation; know its current trust model (permissioned validators in Mainnet 0.0, PoS planned) and what “finality” it provides relative to L1. (espressosys.com)

2.7 Restaking and shared‑security dependencies

• If you rely on EigenDA or other restaked AVSs, confirm slashing is live (EigenLayer rolled out slashing April 17, 2025) and map cascading risk—what happens if an AVS bug triggers broad slashing across operators? Include indemnities or buffers in your risk plan. (coindesk.com)

---

3) Practical examples with fresh details

Example A: Upgrading an OP Stack chain to Stage‑1 guarantees

Checklist we run:

• Fault‑proofs in production: Governance‑approved, permissionless fault proofs are live on OP Mainnet—confirm your fork aligns and remove any residual allowlists. Document the path for Base‑style 7‑day withdrawals in your own docs. (blog.oplabs.co)
• Challenge period: L2BEAT enforces ≥7‑day challenge periods for Optimistic rollups to count as Stage 1; verify your timers (including “air gaps” and grace delays) meet this threshold. (forum.l2beat.com)
• Prover diversity: Enable Kona (Rust) alongside Cannon (Go) and set MAX_GAS_LIMIT consistent with fault‑provability to avoid “unprovable” blocks. Capture this in your change log and ops runbook. (gov.optimism.io)
• Forced inclusion drills: Simulate 12‑hour sequencer downtime; force deposits via OptimismPortal; verify deterministic inclusion and end‑to‑end withdraw. (docs.optimism.io)
• Security Council policy: Record the ≥75% threshold, 14‑day delayed upgrades, and veto process; publish user‑facing guarantees matching the Stage‑1 L2BEAT principle. (gov.optimism.io)

Result: an auditable, publicly documented Stage‑1 rollup posture that external assessors can verify.

Example B: Hardening an Arbitrum Orbit L3 with BoLD and fast exits

• Force‑inclusion and delayed inbox: Confirm default 24‑hour force‑inclusion parameters; if you reduce them for UX, document censorship‑resistance tradeoffs. Wire SDK “forceInclude” paths (InboxTools) into runbooks with gas estimates and custody for L1 fees. (docs.arbitrum.io)
• BoLD Delay Buffer: Configure thresholds to auto‑shorten inclusion times under observed censorship/outages so validators can keep dispute games moving; write incident playbooks that include this. (docs.arbitrum.io)
• Fast withdrawals: Only use committee‑based fast exits on AnyTrust‑style chains with minimum validator/DAC requirements—and always preserve canonical challenge‑secured withdrawal paths. (docs.arbitrum.io)
• MEV policy: If you enable Timeboost, publish a policy for order‑flow sources and fees; audit for builder/sequencer conflicts. (docs.arbitrum.io)

Example C: zk Rollup on alt‑DA (Celestia/EigenDA/Avail)

• DA guarantees:
  • Celestia: show how DAS light clients give availability guarantees, and note the 30‑day sampling/pruning window; ensure archival providers for historical proofs and retrieval SLAs. (docs.celestia.org)
  • EigenDA: document quorums, coding rate γ, and stake thresholds; test retrieval across operator subsets and verify KZG proofs end‑to‑end. (docs.eigencloud.xyz)
  • Avail: prove that your client fetches per‑appID slices and that your relayer validates DAS confidence for each block. (docs.availproject.org)
• Prover stalls and emergency modes: Define what happens when the prover halts (e.g., Polygon zkEVM emergency mode); cap emergency discretion and require public post‑mortems. (docs.polygon.technology)

---

4) Incident‑driven audit tasks you should not skip

• OP Stack stalls: Multiple OP Mainnet “unsafe head stall” incidents in 2024 tied to L1 node instability/blob data availability; design probes that detect divergence between unsafe/safe head and trigger forced‑tx workflows. (status.optimism.io)
• Base outages: Track missed‑block and delayed‑transaction incidents on Base’s status page and ensure your SLOs and autoscaling policies would have contained similar events. (status.base.org)
• Polygon zkEVM emergency: March 24, 2024 emergency state activation to recover from an outage; your audit should check who can trigger emergency, what pauses, and the re‑start controls/timelocks. (forum.polygon.technology)
• zkSync events: 5‑hour Christmas Day 2023 outage due to safety mechanism; 2025 airdrop distribution exploit with fund recovery. Use these to pressure‑test your own “non‑protocol but adjacent” admin key and distribution processes. (cointelegraph.com)

---

5) Emerging best practices we now recommend by default

• Prover diversity and redundancy:
  • OP Stack: run multiple independent fault‑proof implementations (Cannon + Kona) and constrain gas so every block is provable. (gov.optimism.io)
  • ZK stacks: provision a secondary prover path (or third‑party prover marketplace) with SLAs; document GPU/CPU provisioning against your TPS targets. (docs.zksync.io)
• DA risk hedging post‑4844:
  • Alerts on blob data‑gas price; automatic throttles; calldata fallback for critical batches; budget buffers for 10× spikes. (ethresear.ch)
• Strong forced‑inclusion UX:
  • Publish a “user can exit without us” guide. For OP Stack, teach deposit‑based forced transactions; for Arbitrum, delayed inbox/forceInclude. Provide wallet snippets and RPC endpoints. (docs.optimism.io)
• Ordering policy disclosure:
  • If enabling Timeboost (Arbitrum) or Flashblocks (OP), disclose preconfirmation revocation risk, builder policies, and fee splits. (docs.arbitrum.io)
• Shared/decentralized sequencing pilots:
  • Espresso confirmations can reduce equivocation risk and improve cross‑rollup UX; record its BFT trust model today (permissioned validator set; PoS planned) so users don’t confuse it with L1 finality. (espressosys.com)
• Restaking discipline:
  • If relying on EigenLayer/EigenDA, acknowledge that slashing is now live and specify cascading‑risk limits (position sizing, emergency liquidity, governance “kill‑switches”). (coindesk.com)
• Stage alignment:
  • Align with L2BEAT’s 2025 Stages (≥7‑day challenges for ORUs; ≥75% SC compromise threshold) and publish compliance status per environment (mainnet, canary). (l2beat.com)

---

6) Sidechains: what’s different and how to audit them

Sidechains (e.g., Polygon PoS) don’t inherit Ethereum’s security; they run their own consensus and validator set. Your audit must:

• Review validator set size, stake distribution, slashing, and the authority to change these. Log the entity controlling key upgrade multisigs and their threshold/timelocks (e.g., Polygon’s moves to a 13‑member Protocol Council with 7/13 default threshold for regular changes). (forum.polygon.technology)
• Capture consensus client patches and known issues (e.g., Heimdall/Tendermint security fix for invalid block parts dissemination, March 27, 2025). (forum.polygon.technology)
• Treat bridges as critical, not auxiliary: sidechain bridges are the system’s biggest risk. Require canonical, audited escrows, public incident reports, and live monitors for state sync and exit queues. (docs.polygon.technology)

---

7) Concrete deliverables you should require from any security partner

• Threat model and “chain of trust” diagram: settlement, proofs, DA, bridge, sequencer, councils.
• Privilege map and timelock proofs: who can upgrade what, and how fast; include emergency powers and their constraints.
• Forced‑inclusion drills with artifacts: transaction hashes, inclusion timestamps, RPC traces.
• DA resilience report: blob‑price stress test, alt‑DA retrieval tests, archival node plan for Celestia 30‑day windows.
• Prover continuity plan: MTTD/MTTR for prover incidents; fallback prover runbooks and budgets.
• MEV/ordering policy: documented Timeboost/Flashblocks configs, preconfirmation caveats, and builder relations.
• Stage compliance appendix: mapping to L2BEAT Stage‑1/2 criteria with evidence links. (l2beat.com)

---

8) Brief “in‑depth details” on a high‑leverage test: Forced‑inclusion end‑to‑end

Run this before mainnet:

• OP Stack:
  • Halt sequencer in a canary env; post a deposit via OptimismPortal; verify inclusion per the 12‑hour sequencing window rules; use the withdrawal path to prove exits work without the team. Archive logs of L1/L2 heights, timestamps, and portal events. (docs.optimism.io)
• Arbitrum:
  • Submit to the delayed inbox; wait ~24h; call forceInclude via SDK’s InboxTools; show L2 side effects and then finalize a withdrawal after the challenge period. Document how changing delayBlocks/delaySeconds alters this. (docs.arbitrum.io)

Why it matters: these are the only user‑enforceable guarantees during sequencer failure or censorship. Publishing the runbook and hashes is one of the strongest trust signals you can give institutional partners. (scalability.guide)

---

9) What 7Block Labs does differently

• We tie protocol audits to live incident classes (unsafe head stalls, prover halts, DA congestion) and demonstrate your forced‑inclusion and exit invariants under those exact faults.
• We test to Stage‑1 expectations with external benchmarks (L2BEAT 2025), not just internal checklists. (l2beat.com)
• For alt‑DA, we verify the exact light‑client and quorum assumptions you’re making (Celestia DAS windows, EigenDA coding‑rate/quorums, Avail app‑ID filtering) and show your retrieval works across partial operator sets. (docs.celestia.org)
• We document upgrade powers down to signer thresholds and timelocks (Optimism and Arbitrum Security Councils; Polygon Protocol Council), including emergency procedures users should understand before depositing funds. (gov.optimism.io)

---

Key references (selected)

• EIP‑4844 and post‑4844 economics: EF announcements and ethresear.ch analyses; use them to size costs and prepare for blob spikes. (blog.ethereum.org)
• Stage framework for rollups (2025): L2BEAT explainer and forum updates (≥7‑day ORU challenges; ≥75% SC compromise to block/forge L2→L1). (l2beat.com)
• OP Stack fault proofs and prover diversity: OP Labs announcement; Upgrade 16 notes (Kona + Cannon). (blog.oplabs.co)
• Arbitrum Stage‑1 page and BoLD docs; Timeboost preview. (l2beat.com)
• Forced‑inclusion docs for OP and Arbitrum; Base finality guide. (docs.optimism.io)
• Alt‑DA official docs: Celestia (DAS + pruning), EigenDA (erasure+KZG, quorums), Avail (KZG + DAS, app‑IDs). (docs.celestia.org)
• Shared sequencers: Espresso FAQ and Nitro integration notes. (espressosys.com)
• Incident reports/status pages: Optimism status incidents; Base status. (status.optimism.io)
• Polygon governance/emergency docs (Protocol Council draft; zkEVM emergency mode; Heimdall fix). (theblock.co)

---

Bottom line

A modern rollup/sidechain audit must prove—not just claim—that users can (1) exit without your team, (2) withstand sequencer downtime/censorship, (3) avoid “silent” upgrades compromising funds, and (4) survive DA or prover faults while meeting SLOs. If you want a battle‑tested, decision‑maker‑friendly audit that covers protocol, governance, and operations with live drills and external benchmarks, 7Block Labs can help.