Back to Blog 
DeFiWeb3 SecurityAudit
Layer 2 security under the hood: proof systems, upgrade keys, and what actually protects your funds
If you're deploying contracts on an Ethereum L2, the proof system is not your primary security risk. The upgrade keys are.
This guide breaks down the trust assumptions, proof mechanics, and centralization vectors across Arbitrum One, Optimism (OP Mainnet), and Polygon zkEVM — three architectures representing the two dominant rollup paradigms. Polygon zkEVM is included despite its 2026 deprecation because its failure modes are instructive for anyone evaluating ZK rollup deployments.
The goal is straightforward: give you the technical data you need to model risk before you ship.
How rollups derive security from L1
All three networks execute transactions off-chain and anchor state commitments to Ethereum. The difference is how they prove those commitments are correct.
- Optimistic rollups (Arbitrum, Optimism): Assume state transitions are valid. If a validator spots an invalid state root, they submit a fraud proof within a challenge window. Security holds as long as one honest validator exists and has access to the data needed to construct a proof.
- ZK rollups (Polygon zkEVM): Every batch includes a cryptographic validity proof verified on-chain. No challenge window, no honest-watcher assumption for state correctness. The trade-off: circuit complexity becomes the attack surface.
Both models post full transaction data to Ethereum L1 (calldata or EIP-4844 blobs), enabling independent state reconstruction. This data availability layer is what separates rollups from sidechains — if you're evaluating cross-chain bridge security, understanding this distinction is critical. Polygon zkEVM never integrated blob support — a cost disadvantage that contributed to its deprecation.
Fraud proofs: BoLD vs. Cannon
Arbitrum's multi-round interactive proofs
Arbitrum uses BoLD (Bounded Liquidity Delay), deployed to mainnet in February 2025. The mechanism:
- A disputed state assertion triggers an interactive bisection game
- The protocol narrows disagreement through three phases: block-level → a range of 2²⁰ WASM instructions → a single instruction
- That single WASM instruction executes on Ethereum L1 for deterministic adjudication
- The losing party's bond is slashed
Key properties of BoLD:
- Permissionless validation — anyone can post and challenge assertions (previously limited to ~14 allowlisted validators)
- All-vs-all dispute model — one honest defender can simultaneously resist an arbitrary number of malicious challengers, eliminating sequential delay attacks
- Fixed confirmation bound — disputes resolve within ~12.8 days (two 6.4-day challenge periods plus a 2-day Security Council grace period)
- Trustless bonding pools — defending the network requires substantial capital (e.g., 200 WETH per assertion on Arbitrum One), but pools allow collective funding without mutual trust
- Defender capital exposure: ~15% of the attacker's total deployed capital
BoLD was audited by Trail of Bits and underwent a Code4rena competitive audit ($300,500 bounty pool, May 2024). Understanding what audits actually cost at this scale helps contextualize the investment in L2 security infrastructure.
Optimism's single-round fault proofs
Optimism deployed the Cannon fault proof system in June 2024, moving from a fully trusted proposer to permissionless challenges. Before this, the network ran for years with no live proof system — an explicit trust assumption on the centralized proposer.
The mechanism:
- The state transition function compiles to a MIPS virtual machine
- The
op-challengermonitors theDisputeGameFactorycontract for invalid output proposals - Disputes use a bisection game with a maximum depth of 73 levels
- An airgap window adds delay after game resolution before withdrawals execute
- The Guardian role (held by the Security Council) can pause withdrawals or blacklist specific dispute games
Engineering considerations worth noting:
- Cannon historically required patches to disable Go's garbage collector for deterministic execution
- Multi-Threaded Cannon (MT-Cannon) introduced 64-bit MIPS emulation to address memory constraints, but added concurrency risks — deadlocks or thread starvation could theoretically prevent proof generation
- Defender capital exposure: ~109% of the attacker's deployed capital at maximum game depth (~691 ETH cumulative bond)
The capital asymmetry is significant. In a resource exhaustion attack, only well-capitalized institutional entities can reliably serve as honest watchers on Optimism. Arbitrum's BoLD reduces this barrier by an order of magnitude.
Proof system comparison
| Property | Arbitrum (BoLD) | Optimism (Cannon) |
|---|---|---|
| Proof type | Multi-round interactive bisection (WASM) | Single-round MIPS execution |
| Dispute resolution time | ~12 days (fixed upper bound) | 3.5 days per game + airgap |
| L1 gas per dispute | Lower (narrows to one instruction) | Higher (full state replay potential) |
| Delay attack resistance | All-vs-all model, fixed upper bound | Relies on Guardian override |
| L2BEAT stage | Stage 1 | Stage 1 |
| Validator set | Permissionless | Permissionless |
| Defender capital exposure | ~15% of attacker's capital | ~109% of attacker's capital |
ZK validity proofs: Polygon zkEVM's architecture
Polygon zkEVM used a hybrid proof system combining STARKs and SNARKs:
- eSTARK as the primary backend — extended STARK over the Goldilocks field (p = 2⁶⁴ − 2³² + 1), using FRI for polynomial commitments
- Recursive aggregation — STARK proofs aggregate to reduce verification costs
- STARK-to-SNARK conversion — the final step converts to a Groth16 SNARK (FFLONK scheme) for constant-size on-chain verification via BN254 pairing curves, reducing L1 verification gas from ~5M to ~350K
EVM opcodes were implemented via zkASM, a custom assembly language operating within the ZK circuit. The prover (zkProver) was centralized and operated exclusively by Polygon Labs.
ZK circuit vulnerability classes
The circuit complexity introduced vulnerability classes absent from optimistic rollups:
- Underconstrained free inputs: zkASM patterns where free inputs lacked sufficient polynomial constraints. Attackers could manipulate execution paths while still generating valid proofs.
- Dual execution path attacks: Different paths consuming different ZK counters could both produce valid proofs. The FreeVer tool (academic research, 2025) found 6 soundness issues and 1 completeness issue, all confirmed high-impact by Polygon.
- STARK↔SNARK field incompatibility: The Goldilocks field (64-bit) and the BN254 field (254-bit) have different arithmetic properties. Verichains discovered in late 2023 that the Merkle root computation in this conversion layer could be exploited to forge proofs entirely. Patched December 2023.
- ecrecover discrepancy: Implementation differences between zkASM's ecrecover and standard EVM could have allowed proof generation for non-compliant transactions.
- Integer overflow in storage state machine: Pre-launch audits by Spearbit found overflow vulnerabilities that could grant unauthorized state manipulation to dishonest provers.
The takeaway for anyone evaluating ZK rollups: the attack surface shifts from game theory (can we incentivize honest watchers?) to cryptographic implementation correctness (are the circuits actually sound?). Bugs in ZK circuits are harder to detect and potentially catastrophic — a valid-looking forged proof can drain all funds.
Upgrade keys override proof systems
This is the section that matters most for risk modeling.
If a multisig can upgrade the rollup's L1 contracts without delay, the proof system is irrelevant. The security model collapses to "trust the key holders." If you've worked with upgrade patterns in smart contracts, you'll recognize this as the same proxy upgradeability risk — amplified to protocol scale.
Arbitrum: DAO-controlled with timelocks
- DAO governance controls all upgrades (4.5% quorum threshold)
- Regular upgrade path: L2 Timelock (8 days) → L2→L1 message (6.4-day challenge period, extendable by 2 days) → L1 Timelock (3 days). Total: ~17+ days
- Security Council: 12 members, DAO-elected in semi-annual cohort elections, publicly named
- Emergency path: 9/12 multisig can upgrade instantly (no delay)
- Non-emergency path: 7/12 threshold, subject to timelocks
- The 8-day L2 timelock is deliberate — it exceeds the 6.4-day BoLD challenge period, preventing the Council from altering contract rules mid-dispute
- Exit window: Users can withdraw before any DAO-initiated upgrade executes
Optimism: no exit window
- All contracts upgradable via
SuperchainProxyAdmin, controlled by a 2/2 multisig (Optimism Foundation + Security Council) - No timelock on regular upgrades — changes can execute instantly
- No exit window — users cannot withdraw before an upgrade takes effect
- Guardian role (held by Security Council) can pause withdrawals across the entire Superchain for up to 3 months
- Deputy Guardian (held by Foundation) enables rapid incident response; removable by Council
- DAO governance signals intent via votes but has no direct on-chain upgrade authority
The absence of an upgrade timelock is Optimism's most significant centralization vector. If the 2/2 multisig is compromised — through key theft, coercion, or collusion — contract logic governing the bridge and fault proof resolution can change with zero user recourse. This is a governance attack surface that exists independent of the proof system.
Polygon zkEVM: no-timelock emergency powers
- Regular upgrades: 2/3 developer multisig with a 10-day timelock
- Emergency state: 6/8 Security Council can activate
activateEmergencyState, which halts sequencing, blocks the bridge, and disablesforceBatch - No DAO governance mechanism for zkEVM specifically
- Both sequencer and aggregator were centralized under Polygon Labs
Upgrade governance summary
| Property | Arbitrum | Optimism | Polygon zkEVM |
|---|---|---|---|
| Regular upgrade delay | 8-day minimum (exceeds challenge period) | 0-day (instant) | 10-day timelock |
| Emergency bypass | 9/12 multisig | 2/2 multisig | 6/8 Security Council |
| Exit window | Yes | No | No |
| DAO on-chain authority | Yes | No (signaling only) | No |
Get the DeFi Protocol Security Checklist
15 vulnerabilities every DeFi team should check before mainnet. Used by 30+ protocols.
No spam. Unsubscribe anytime.
Sequencer centralization and censorship resistance
All three networks run (or ran) centralized sequencers. The sequencer cannot fabricate invalid state — L1 settlement enforces correctness — but it can reorder, delay, or censor transactions. This creates MEV extraction opportunities identical to those on L1, but concentrated in a single operator.
- Arbitrum: Sequencer operated by the Arbitrum Foundation. Users can force-include transactions via the L1
DelayedInbox. Sequencer decentralization planned but still in progress. - Optimism: Sequencer operated by the Optimism Foundation. Users can force transactions on L1 with up to a 12-hour delay. If the sequencer goes offline beyond a 30-minute drift threshold, it enters a catch-up phase producing blocks at a 1:1 ratio with L1 until resynchronized.
- Polygon zkEVM: Sequencer and aggregator operated by Polygon Labs.
forceBatchwas only enabled late in the chain's lifecycle, ahead of the deprecation announcement.
Liveness failures: what broke and why
- Arbitrum (December 2023): Inscription-related traffic consumed ~90% of network load, causing a ~1.5-hour sequencer outage. Secondary nodes failed to take over due to a concurrent software upgrade conflict.
- Optimism: Multiple minor RPC-related incidents during early operation. No prolonged outages documented at the sequencer level.
- Polygon zkEVM (March 2024): A 10–14 hour outage triggered by an L1 block reorganization. The L2 synchronizer failed to detect a dropped global state update transaction, causing the sequencer to produce batches with corrupted timestamps and an invalid Global Exit Root. L1 rejected the batches, halting proof generation entirely. Recovery required declaring Emergency State, manually rewriting the ROM architecture, force-upgrading L1 verifiers, and re-executing thousands of orphaned transactions. Users had no general-purpose mechanism to force-exit assets during the outage.
These incidents illustrate why a defense in depth approach matters for L2 deployments — no single layer of protection is sufficient.
Audit history and critical incidents
Understanding audit coverage provides context for the real ROI of security investment on these networks.
Arbitrum
- Audits: Trail of Bits (BoLD, Nitro v3.9.3), Code4rena competitive audit ($300.5K pool), ChainSecurity
- Bug bounty: Immunefi, up to $2M for critical vulnerabilities
- Notable incident: 2024 Security Council bug fix protecting ~$100M in TVL across Arbitrum dApps. No known exploits resulting in user fund losses on core protocol.
Optimism
- Audits: Core dev teams (OP Labs, Base, Succinct Labs) plus external auditors
- Bug bounty: Immunefi. $2M payout in February 2022 for the infinite mint vulnerability
- Notable incident: A flaw in the OVM's
SELFDESTRUCTopcode handling allowed unlimited synthetic ETH minting on L2 through contract reuse loops. The L2 token was returned but the liability record was not purged, enabling balance triplication. Discovered by a whitehat before exploitation.
Polygon zkEVM
- Audits: 35 components audited 3 times by 26 researchers (~4 months). Hexens found 9 vulnerabilities (4 critical). Spearbit found 10 critical, 1 high, 4 medium. Dedicated ZK circuit/cryptography audit by Spearbit.
- Bug bounty: Immunefi
- Notable incidents: STARK↔SNARK proof forgery (Verichains, patched December 2023); FreeVer research uncovering 6 soundness + 1 completeness issue in zkASM circuits (2025, confirmed high-impact)
Polygon zkEVM deprecation: lessons for ZK rollup evaluation
Polygon announced the zkEVM Mainnet Beta shutdown in mid-2025. Contributing factors:
- TVL below 1M
- Never integrated EIP-4844 blob support, losing cost competitiveness against optimistic rollups
- ZK counter limits blocked integration with complex DeFi protocols
- Circuit complexity created vulnerability classes requiring deep cryptographic expertise to audit
- Prover remained centralized throughout the chain's lifetime
The ZK technology was redirected to Polygon's AggLayer and CDK framework. The AggLayer uses Pessimistic Proofs — a ZK-based accounting abstraction that assumes every participating L2 is fraudulent by default. Rather than validating full state execution across chains, it verifies only that no chain withdraws more from the unified bridge than it originally deposited. This constrains the blast radius of any single compromised chain to its own capital.
The sequencer continues running for 12 months with
forceBatch permanently enabled for user exits.Using this data for risk modeling
No Ethereum L2 has achieved Stage 2 as of April 2026. Every deployment carries residual trust assumptions. Here's how to use the above when making deployment or integration decisions:
- Evaluate the upgrade path, not the proof system. A 9/12 emergency multisig (Arbitrum) or a 2/2 instant-upgrade multisig (Optimism) defines your actual trust boundary. Model scenarios where these keys are compromised.
- Quantify your exit window. Arbitrum's ~17-day DAO upgrade pipeline gives users time to withdraw. Optimism's zero-delay regular upgrades do not. If your protocol holds significant TVL on an L2, this gap directly affects your users' risk exposure.
- Assess capital requirements for honest validation. If you plan to run a validator or watchdog, Arbitrum's BoLD requires ~15% of an attacker's capital to defend. Optimism's Cannon requires ~109%. This determines whether independent validation is economically viable for your team.
- For ZK rollup integrations: Audit the circuit constraints, not just the smart contracts. Underconstrained free inputs, field incompatibilities in proof conversions, and ZK counter limits are categories your auditors need to specifically target.
- Monitor data availability. Both Arbitrum and Optimism post full DA to Ethereum L1. If you're evaluating alternative DA layers (e.g., Arbitrum Nova's AnyTrust DAC), understand that weaker DA = weaker fraud proof guarantees.
- Track governance changes. Security Council compositions, multisig thresholds, and timelock durations change through governance proposals. Subscribe to governance forums for any L2 where you hold meaningful exposure.
The proof system is the mechanism. The upgrade keys are the policy. Secure deployments require modeling both.
Before deploying on any L2, run through a pre-audit security checklist to ensure your contracts are hardened for the specific trust model of your target chain.
Partner with Zealynx
At Zealynx, we audit smart contracts deployed across L1 and L2 environments — including Arbitrum, Optimism, and ZK rollup chains. We evaluate not just your contract logic, but the trust assumptions of the infrastructure your protocol depends on. Whether you need a full security audit or a targeted review of your L2 integration points, we help you ship with confidence.
FAQ: Layer 2 security
1. What is a rollup and how does it differ from a sidechain?
A rollup executes transactions off-chain but posts transaction data back to Ethereum L1, allowing anyone to independently verify state correctness. A sidechain runs its own consensus and does not anchor data to Ethereum — if sidechain validators collude, funds can be stolen with no L1 recourse. Rollups inherit Ethereum's security guarantees because the data needed to reconstruct state is always available on L1. This distinction matters for risk modeling: rollup users can always force-exit through L1, while sidechain users depend entirely on the sidechain's own validator set.
2. What is a fraud proof and how does it protect funds on an optimistic rollup?
A fraud proof is a mechanism that allows any validator to challenge an invalid state transition posted to Ethereum. In optimistic rollups like Arbitrum and Optimism, state updates are assumed valid unless someone proves otherwise within a challenge window (typically 7–14 days). If a validator detects a fraudulent state root, they submit a fraud proof to L1 — the disputed computation is re-executed on-chain, and the dishonest party's bond is slashed. Security relies on at least one honest validator monitoring the chain and having the capital to post a challenge bond.
3. What does "Stage 1" vs "Stage 2" mean for L2 maturity?
L2BEAT classifies rollups into maturity stages based on their trust assumptions. Stage 0 means the rollup depends on a centralized operator with no live proof system. Stage 1 means a working proof system exists and users can force-exit, but a Security Council can still override the system (e.g., emergency upgrades). Stage 2 means the proof system is fully trustless — the Security Council can only act within tightly constrained, auditable bounds. As of April 2026, no major L2 has reached Stage 2. Both Arbitrum and Optimism sit at Stage 1, meaning their Security Councils remain a central trust assumption.
4. What are upgrade keys and why are they a bigger risk than the proof system?
Upgrade keys are the private keys (typically held by a multisig wallet) that control the ability to modify a rollup's L1 smart contracts. If a multisig can push a contract upgrade with no timelock or exit window, the key holders can change bridge logic, disable fraud proofs, or drain locked funds — regardless of how robust the proof system is. For example, Optimism's 2/2 multisig can upgrade all contracts instantly with no user exit window. The proof system only protects against invalid state transitions; upgrade keys can rewrite what counts as "valid." This is why evaluating governance matters more than evaluating proof design.
5. Can a centralized sequencer steal my funds on a Layer 2?
No — a centralized sequencer cannot fabricate invalid state transitions because L1 settlement enforces correctness through fraud proofs or validity proofs. However, a centralized sequencer can censor your transactions (refusing to include them), reorder transactions to extract MEV, or go offline entirely, temporarily preventing you from transacting. On Arbitrum and Optimism, users have a fallback: they can force-include transactions directly through L1 contracts, bypassing the sequencer. This force-inclusion path has a delay (up to 12 hours on Optimism), but it guarantees censorship resistance as long as Ethereum L1 is operational.
6. How should I evaluate which L2 is safest for deploying a high-TVL protocol?
Focus on four factors: (1) Exit window — can your users withdraw before a governance-initiated upgrade takes effect? Arbitrum provides ~17 days; Optimism provides zero. (2) Upgrade authority — what multisig threshold controls contract changes, and is there a timelock? (3) Validator economics — can you afford to run an independent watcher? Arbitrum's BoLD requires ~15% of an attacker's capital vs. Optimism's ~109%. (4) Data availability — does the rollup post full transaction data to Ethereum, or does it rely on a committee (like Arbitrum Nova's AnyTrust DAC)? For high-TVL deployments, prioritize chains with timelocked upgrades, exit windows, and economically viable independent validation.
Glossary
| Term | Definition |
|---|---|
| Fraud proof | Challenge mechanism proving an invalid state transition was posted to L1, triggering bond slashing. |
| ZK-Rollup | Layer-2 scaling solution using zero-knowledge proofs to batch transactions while inheriting Ethereum security. |
| Timelock | Smart contract mechanism enforcing mandatory delay between initiating and executing critical protocol changes. |
Get the DeFi Protocol Security Checklist
15 vulnerabilities every DeFi team should check before mainnet. Used by 30+ protocols.
No spam. Unsubscribe anytime.
