If you've used Ethereum in the past year there's a good chance you weren't on Ethereum. You were on Arbitrum, Base, OP Mainnet or one of a dozen other layer 2 networks, and the transaction was cheap because of that.
What a rollup actually is
Execution happens somewhere else. The data comes back.
ethereum.org puts it plainly: "The transaction data in the rollup is submitted to layer 1, but the execution is done separately by the rollup." Your transaction runs on a chain the rollup operator controls, and then a record of it is posted to Ethereum.
The security inheritance is real but narrow. Because the data is on Ethereum, "reverting a rollup transaction requires reverting Ethereum." Nobody can quietly erase your transaction or fabricate a different history.
That is the guarantee. Ethereum will not let anyone rewrite what happened. It has nothing to say about who is allowed to change the contracts holding your deposit.
Optimistic and validity rollups, precisely
The difference is not speed or cost. It is when validity is established.
An optimistic rollup assumes transactions are valid and allows them to be challenged afterwards during a window. A validity rollup, usually called a ZK rollup, produces a cryptographic proof that Ethereum verifies before accepting the new state.
One asserts correctness upfront and proves it. The other assumes correctness and waits to see if anyone objects. Everything downstream, including how long your withdrawal takes and who can strand it, follows from that single choice.
ZK does not mean instant withdrawals. With the current L2BEAT data, ZKsync Era shows a 3 hour delay and Mantle 12 hours. Starknet, Linea, Scroll and Aztec show none. The proof system removes the need for a challenge window; it does not remove whatever delay the chain's own design adds.
The sequencer
Somebody has to decide what order transactions go in. On every major L2 today, that somebody is one company.
Arbitrum's own documentation describes the Sequencer as ordering incoming transactions and managing the batching, compression and posting of data to the parent chain, and it currently runs as a single centralized entity. Base and OP Mainnet are the same shape.
What a sequencer can do: order your transaction after someone else's, delay it, and see it before it executes.
What it cannot do: forge a state that Ethereum will accept, or censor you permanently.
When the sequencer stops
Every serious rollup has a way to submit transactions without the sequencer's cooperation. What differs is how long it takes and whether it exists at all.
On OP Stack chains, including Base and OP Mainnet, you submit directly to the OptimismPortal contract on Ethereum. Node software must include it within the sequencing window, set to 3,600 Ethereum blocks or roughly 12 hours by default.
On Arbitrum One, you submit to the delayed inbox and then call forceInclusion once the delay has elapsed. That delay is the lesser of two parameters, and under normal conditions is about 24 hours.
You will see "Arbitrum force inclusion takes 30 minutes." It does not. Thirty minutes is a separate threshold parameter governing when a buffer starts depleting. The buffer shrinks under sustained censorship, so the delay falls toward 30 minutes only after someone has already been censoring for a long time. On a normal day the wait is a day.
Arbitrum's buffer design is genuinely clever: persistent censorship shortens the escape hatch rather than lengthening it. It replenishes at roughly one minute for every twenty minutes without delays, which works out to about a day restored every twenty days.
L2BEAT publishes what happens on each chain when the sequencer fails:
| chain | if the sequencer fails | if the proposer fails |
|---|---|---|
| Base | Self sequence, 12h delay | Self propose |
| OP Mainnet | Self sequence, 12h delay | Self propose |
| Arbitrum One | Self sequence, 1d delay | Self propose |
| ZKsync Era | Enqueue via L1 | Replace proposer |
| Starknet | Log via L1 | Self propose |
| Mantle | not published | Cannot withdraw |
| Linea | No mechanism | Cannot withdraw |
"No mechanism" means what it says. On Linea, if the sequencer will not process your transaction, there is no path to force it. Forcing your transaction achieves nothing if no one can advance the chain's state afterwards, which is what "Cannot withdraw" in the second column means.
Who can change the contracts
OP Mainnet. The L1 ProxyAdmin is a 2-of-2 between the Optimism Foundation and the Security Council, and it can upgrade most system contracts. The published privileged-roles page specifies no timelock. Separately, a Guardian role can pause withdrawals, and the documentation states that a compromised Guardian could pause them for three months before they automatically resume.
Base. Upgrades need a 2-of-2 between CB Signers, a 3-of-6 Coinbase multisig counting as one signer, and at least 8 of 11 independent Security Council members. Nine approvals in total, and the eleven council members are named, geographically distributed entities rather than an abstraction. Base shipped permissionless fault proofs in October 2024 and reached Stage 1 in April 2025.
Arbitrum One. A 12-member Security Council, elected in two cohorts of six every six months. Non-emergency actions run through a 3 or 8 day waiting period on L2 plus 3 days on L1. Emergency actions need 9 of 12 and execute immediately, with no delay at all.
L2BEAT captures the consequence in one column, the exit window, which asks whether you can withdraw before an upgrade takes effect:
Base None
OP Mainnet None
Mantle None
Linea None
Scroll None
Lighter None
Arbitrum One Emergency: None Regular: 10d
Starknet Emergency: None Regular: 7d
ZKsync Era Emergency: None Regular: 4d 3hEvery chain in that list has no exit window for an emergency upgrade. If the key holders decide to change the contracts under the emergency path, there is no period in which you can leave first.
Stage 1 does not mean decentralized
As of today Base secures about $11.00 billion and Arbitrum One about $10.21 billion, and both are Stage 1. Both also retain an immediate emergency upgrade path with no exit window.
Stage 1 is a real and meaningful milestone. It is not the same as nobody being able to change the rules while your money is inside.
Other numbers that circulate and are wrong
"Blob data is stored on Ethereum permanently." No. Blobs are retained for 4,096 epochs, roughly 18 days. After that, reconstructing the data depends on third parties who chose to keep it.
"Blobs: 3 target, 6 maximum." Superseded. EIP-7691 raised it at Pectra in May 2025, and Fusaka's EIP-7892 moved the limits onto a schedule set in client configuration. The specification says outright that the actual values are beyond its scope, so there is no citable constant for today's limit.
"Optimistic rollups have a 7-day withdrawal delay." Approximately, and only on some. On OP Mainnet the 7 days is a single onchain parameter, proofMaturityDelaySeconds set to 604800. Arbitrum One is a 6.4 day challenge resolution period, which already includes a two-day grace period for its Security Council to intervene.
"The challenge window is 7 days because fraud proofs take 7 days to compute." No. It is sized so an honest challenger can reliably get a transaction onto Ethereum even if somebody is trying to censor them.
Securing the unseen
Four questions you can answer about any rollup before you put money on it, all from published data.
Who runs the sequencer, and is it one company? If it stops, is there a documented way to force your transaction in, and how long does it take? If it stops, can anyone advance the state so your withdrawal actually completes? And who can upgrade the contracts, on what delay, and is there an emergency path that skips the delay entirely?
The answers are published. L2BEAT maintains them per chain, and every major rollup documents its own privileged roles, usually more honestly than its marketing does.
"Inherits Ethereum's security" is true about transaction history and silent about everything else. The silence is where the risk lives.
Learn more at 0xhades.io/research
Sources
13 references · 4 primary- L2BEAT, Risk Analysis Per-chain sequencer failure, proposer failure and exit window rows quoted throughout, read 17 August 2026. l2beat.com
- L2BEAT, Scaling Summary Stage classifications and value secured, including Base at about $11.00B and Arbitrum One at about $10.21B, both Stage 1. l2beat.com
- ethereum.org, Learn about layer 2 The definition of a rollup, the security inheritance from posting data to layer 1, and the distinction between optimistic and zero-knowledge rollups. ethereum.org primary
- Arbitrum documentation, The Sequencer The Sequencer's role, its current centralisation, the delayed inbox and forceInclusion, and the delayBlocks, delayBuffer and threshold parameters. docs.arbitrum.io
- Arbitrum documentation, BoLD Permissionless validation and the 6.4 day challenge resolution period including the two day Security Council grace period. docs.arbitrum.io
- Arbitrum DAO Constitution The 12 member Security Council, two cohorts of six, and the 9-of-12 emergency path that executes immediately. docs.arbitrum.foundation
- Optimism documentation, Sequencer outages Bypassing the sequencer via the OptimismPortal contract and the 12 hour default sequencing window. docs.optimism.io
- Optimism documentation, Privileged roles The L1 ProxyAdmin 2-of-2, the absence of a specified timelock, and the Guardian's three month withdrawal pause ceiling. docs.optimism.io
- OP Stack specification, Withdrawals The seven day challenge period on proven withdrawals, set by proofMaturityDelaySeconds at 604800. specs.optimism.io
- Base documentation, Security Council The 2-of-2 between CB Signers and an 8-of-11 council, permissionless fault proofs in October 2024, Stage 1 in April 2025. docs.base.org
- EIP-4844: Shard Blob Transactions Blob retention of 4096 epochs, roughly 18 days, after which availability depends on third parties. eips.ethereum.org primary
- EIP-7691: Blob throughput increase The Pectra increase that superseded the original 3 target and 6 maximum blob figures. eips.ethereum.org primary
- EIP-7892: Blob Parameter Only Hardforks Blob limits moved to a schedule set in client configuration, with the specification stating the actual values are beyond its scope. eips.ethereum.org primary