An institution weighing whether to settle, issue or hold assets on an Ethereum layer 2 is really asking one question: if this network is compromised, censored or upgraded against its interest, what happens to the assets, and how long is there to react? "Built on Ethereum" says little until it is broken down into a proof system, a sequencer, an exit window and a set of keys. This is that breakdown, written for a risk committee rather than a developer. It is not investment, legal or accounting advice.
What a rollup actually is
A rollup executes transactions away from the Ethereum base chain (L1) and periodically commits the results back to it. What separates a rollup from an independent chain that merely calls itself "Ethereum-compatible" is that its transaction data, and a mechanism for proving its results correct, live on L1. Ethereum's developer documentation, last updated 13 April 2026, defines the two families by how they establish correctness: an optimistic rollup assumes transactions are valid by default and only runs the computation if a challenge is raised, while a zero-knowledge rollup runs computation offchain and submits a validity proof to the chain.
Optimistic rollups
Optimistic systems, such as Arbitrum One and OP Stack chains including OP Mainnet and Base, post a new state and treat it as correct unless someone disputes it within a challenge period. Arbitrum's documentation for its BoLD dispute protocol describes the dispute as a bisection game: the parties narrow their disagreement until a single step of execution remains, and an onchain contract executes that step to decide who was right. The same documentation says anyone can take part in validation, including opening challenges.
Zero-knowledge rollups
Validity-proof rollups instead submit a cryptographic proof that a contract on L1 verifies before the new state is accepted. There is no challenge period for state correctness, because correctness is checked rather than assumed and disputed. The open questions move elsewhere: who generates the proofs, how often, and what happens if they stop.
The sequencer: what it can and cannot do
Most large rollups today rely on a single, operator-run sequencer that orders transactions and posts them to L1. Arbitrum's documentation describes the confirmations its sequencer's feed gives before L1 finality as "soft finality", and notes that their reliability depends on the sequencer operating honestly and without significant downtime. What a sequencer can do is reorder, delay or refuse to include a transaction. What it should not be able to do, on a correctly implemented rollup, is get an invalid state accepted by the proof system or move a user's funds outside the contracts that govern withdrawals.
Censorship is handled by mechanism rather than by promise. Users can submit a transaction directly on L1 and force its inclusion after a delay; L2BEAT records that delay as up to one day on Arbitrum One and up to 12 hours on OP Mainnet. The useful question for an operator is not whether it promises not to censor, but how long a user must wait, and through which published mechanism, to get around it.
Withdrawal and challenge periods are exit risk, not settlement speed
On an optimistic rollup, a standard withdrawal to L1 cannot complete until the challenge period has passed without a successful dispute. L2BEAT records that period as 6 days 8 hours on Arbitrum One, extendable to 12 days 17 hours if a dispute is played out slowly, and up to 10 days 3 hours on OP Mainnet once dispute extensions are counted. Third-party "fast withdrawal" services front the funds for a fee and take on that waiting risk themselves; that is a transfer of risk, not a shorter protocol guarantee. On a validity-proof rollup there is no dispute window, so the delay depends on how often proofs are produced and verified.
This period is separate from the governance exit window described below, which protects against an unwanted code upgrade rather than an incorrect state. A rollup can pair a short withdrawal period with a long, short or absent governance exit window, so the two should be recorded as two numbers, never one.
Upgrade keys and security councils
Rollup contracts are still generally upgradeable, which means a small group of keyholders can change the rules that govern users' funds. The number of signatures required, and how much warning users get before an upgrade takes effect, is what a diligence process should record, rather than a project's own description of its decentralisation. Proof of Talk has set out the general question in who actually controls a protocol. For rollups specifically, L2BEAT's project pages, read on 16 September 2026, record:
- Arbitrum One: a Security Council of 12 members in two six-seat cohorts with staggered terms, which can execute an emergency upgrade with 9 of 12 signatures and no exit window; upgrades that go through the DAO's ordinary path give users an exit window of roughly 17 days.
- OP Mainnet: upgrades require both a 10-of-13 Security Council and the Optimism Foundation, in a 2-of-2 arrangement, and take effect as soon as both sign, "with no onchain delay or prior notice".
The reading for a risk committee: an emergency council can, by design, act as quickly as its threshold of signers can meet. That is useful during an active exploit, and it is also why the size, independence and threshold of that council deserve as much scrutiny as the proof system. Whether an exit window is long enough depends on how quickly an institution's own operations could actually move assets off the chain, which is worth testing rather than assuming.
Data availability: where the record lives
A proof system is only as good as the data it works on. If transaction data is not published where a challenger or prover can retrieve it, neither disputing a bad state nor reconstructing the chain after an operator disappears is possible. Rollups post this data to Ethereum in "blobs", and Ethereum's Fusaka upgrade, which went live on 3 December 2025, introduced PeerDAS, under which nodes no longer each store all blob data but the network as a whole still guarantees it can be reconstructed. Systems that publish data elsewhere, to a separate committee or network, are generally called validiums or optimiums rather than rollups, and they replace Ethereum's data guarantee with a separate trust assumption. That distinction belongs in any diligence memo alongside the proof system and the keys.
L2BEAT's Stages: an independent maturity framework
L2BEAT, an independent research organisation that tracks layer 2s, publishes a Stages framework, last updated 23 July 2025, that grades rollups on what would have to fail before users lose the ability to exit. In outline:
- Stage 0: the project calls itself a rollup, posts its state and data on L1, and makes source-available software that can reconstruct its state.
- Stage 1: a working proof system is in place, and the only way (other than bugs) to block withdrawals indefinitely or push an invalid one is to compromise at least 75% of the Security Council; upgrades by anyone outside that council must give users at least seven days to exit.
- Stage 2: the proof system is permissionless, users have at least 30 days to exit before an unwanted upgrade, and the Security Council may act only on errors detected onchain.
L2BEAT's summary, read on 16 September 2026, lists Arbitrum One, OP Mainnet and Base at Stage 1. A handful of projects are listed at Stage 2, among them Aztec, which reached it after its governance revoked ownership of the rollup contract in June 2026; none of the three chains above is among them. A diligence process should ask for the current stage and when it was assigned, since a stage can be lost as well as gained.
Why exchanges and brokers launch their own layer 2s
Several trading venues have chosen to operate their own rollup rather than build only on someone else's. Coinbase announced Base, built on Optimism's OP Stack, on 23 February 2023, and opened it to the public on 9 August 2023; CoinDesk reported at the February announcement that Coinbase described Base as a bridge for users into the crypto economy, drawing on its existing verified user base and fiat onramps. The Block reported on 24 October 2024 that Kraken was launching Ink, also on the OP Stack, and CoinDesk reported on 18 December 2024 that Ink had gone live on mainnet months ahead of its original schedule. Robinhood announced on 30 June 2025 that it was developing a layer 2 based on Arbitrum, "optimized for tokenized real-world assets"; it opened a public testnet on 10 February 2026 and launched the public mainnet of Robinhood Chain on 1 July 2026.
What a venue gains by running its own chain is operational control: it sets the fees, runs the sequencer and can connect settlement to its existing custody and compliance systems. That is precisely what a risk committee should examine, because the party that benefits from operating the sequencer is the party users are trusting not to misuse it. The stage, sequencer and security council questions above apply to venue-run rollups exactly as they do to any other, and should be asked on the same basis.
Base on the Paris 2026 programme
At Proof of Talk's Paris edition, at the Louvre Palace on 2–3 June 2026, the agenda listed a ten-minute slot titled "Base Announcement" on the Taostats Stage on 3 June, with Xen Baynham-Herd of Base as the listed speaker. No record of what was said has been published, so nothing here is attributed to that session beyond the agenda entry.
Bitcoin layer 2s are a different problem
Everything above is specific to Ethereum's rollup design, in which data and a proof system sit on the base chain. Bitcoin layer 2s rest on different mechanisms and different trust assumptions, and Proof of Talk has covered them separately in Bitcoin's layer 2 and payment-rail designs. The two frameworks should not be blended: the Stages framework was written for rollups that post their data and proofs to a base chain.
A diligence checklist
A rollup's technical configuration says nothing about whether an asset issued on it suits a given mandate; that is a question for counsel and an allocator's own process. For the technical question alone, a risk committee can reasonably ask a counterparty for:
- The proof system in use, fraud proof or validity proof, and whether anyone can submit a challenge or proof, or only an allowlist.
- The current L2BEAT stage, when it was assigned, and any earlier downgrade.
- The signing threshold and membership of any security council or other upgrade authority.
- The exit window, in days, for a non-emergency upgrade, recorded separately from the ordinary withdrawal delay.
- Where transaction data is published, and whether the system is a rollup, a validium or a hybrid.
- The forced-inclusion mechanism available if the sequencer censors a transaction, and how long it takes.
How assets move once issued on infrastructure like this is covered in interoperability between chains and legacy rails.