# Rollup Decentralization: Upgrade Keys and Exit Windows

> Rollup decentralization by layer 2: who can upgrade the bridge contracts, how many signers it takes, the upgrade delay against the exit window and proof status.

Markdown copy of https://voltfincrypto.com/apps/rollup-decentralization

**Question:** Who can upgrade each rollup's bridge contracts, and how much notice do users get before an upgrade?

- Kind: Table in Voltfin Strata
- Topic: [Layer 2s](https://voltfincrypto.com/topics/layer-2)
- Chains: Ethereum, Base, Arbitrum, OP Mainnet, ZKsync, Linea, Scroll, Unichain, World Chain, Ink, Mantle, Blast, Starknet, Katana
- Status: Planned. The data is not published yet, so this page states no figure; each figure will open its receipt when it is.

A rollup's bridge contracts on Ethereum hold the assets of everyone who uses it, and most of them can still be upgraded. This table reads, for each covered rollup, who holds that power, from the proxy admin behind its bridge, portal and inbox contracts to the account that finally controls it: a multisig, a timelock or a governance contract. For a multisig, it shows how many signers must agree.

The second half of the table is about time. It sets the delay before a non-emergency upgrade takes effect against the time a user needs to withdraw. It also shows whether the proof system is live and open to anyone and whether users can force a transaction through Ethereum if the sequencer ignores them. These are the facts behind the stages the Ethereum community uses to describe rollup maturity.

Every value is read from the contracts at a pinned Ethereum block and links to that read. The table describes what the contracts allow; it does not grade any rollup as safe or unsafe.

## Blueprint

One row: One row per rollup, read at a pinned Ethereum block

- **Rollup** (`rollup`): The rollup whose Ethereum contracts the row reads.
- **Proof system** (`proof_system`): The proof system (fault proofs, validity proofs or none) and whether anyone can submit or challenge proofs.
- **Upgrade controlled by** (`upgrade_holder`): The account that finally controls the bridge proxies: a multisig, a timelock, a governance contract or a combination.
- **Holder address** (`holder_address`): The address of that controlling account, linked to its contract.
- **Signers required** (`threshold`): For a multisig holder, the signatures required out of its signers, from getThreshold() and getOwners().
- **Security council** (`council`): The security council's threshold and signer count and the powers it holds, where the rollup has one.
- **Upgrade delay** (`upgrade_delay`, days): The shortest delay before a non-emergency upgrade takes effect, from the timelock or governance contract.
- **Withdrawal time** (`withdrawal_time`, days): The median time for a native withdrawal to become final, from the withdrawal times dashboard.
- **Exit window** (`exit_window`, days): Upgrade delay minus withdrawal time; negative when an upgrade can land before users could leave.
- **Forced inclusion** (`forced_inclusion`): Whether users can force a transaction through Ethereum and the delay before the rollup must include it.
- **Last upgrade** (`last_upgrade`): The date of the most recent implementation change on the rollup's bridge contracts.
- **Receipt** (`receipt`): The pinned block and the reads behind the row.

## How it will be measured

- The admin of each bridge, portal and inbox proxy is read from its ProxyAdmin owner() or the EIP-1967 admin slot at a pinned block, and followed to the account that finally controls it.
- Multisig thresholds and signer counts come from getThreshold() and getOwners() on each Safe; timelock delays come from getMinDelay() or the contract's own delay setting.
- Proof status is read from the contracts: the respected game type and game implementations on OP Stack chains, whether validation is open to anyone on Arbitrum and the verifier contracts on zk rollups.
- The exit window is the upgrade delay minus the time a withdrawal takes, using the withdrawal times measured on this site; a negative window means an upgrade can take effect before a user could leave.
- Forced inclusion is checked from the contracts that accept transactions from Ethereum, with the delay after which the rollup must include them.

## Data it needs

- `address_labels` (to build): Labels for known addresses: exchanges, bridges, protocols, funds, treasuries, sanctioned addresses and known attackers.
- `governance_votes` (to build): Proposals, votes, voting power and turnout in on-chain governors, with off-chain votes recorded with their source.
- `l2_activity_daily` (to build): Per layer 2 per day: transactions, active addresses, fees users paid on the L2, and what the L2 paid Ethereum to settle and post data.
- Source: ProxyAdmin owner() and EIP-1967 admin and implementation slots of each rollup's bridge, portal and inbox proxies on Ethereum
- Source: Safe getThreshold() and getOwners() of upgrade and security council multisigs at a pinned block
- Source: Timelock getMinDelay() or equivalent upgrade delay settings
- Source: OP Stack respectedGameType() and DisputeGameFactory gameImpls(), Arbitrum validator settings and zk rollup verifier contracts
- Source: Forced inclusion paths: OptimismPortal deposits, the Arbitrum delayed inbox and the zk rollups' priority queues
- Source: Upgraded events on each proxy, for the date of the last implementation change

## Questions

### What does it mean that a rollup can be upgraded?

Its bridge contracts on Ethereum sit behind proxies whose code can be replaced. Whoever controls the proxy admin can change how deposits and withdrawals work, so the safety of funds rests on that party as well as on the proof system.

### What is an exit window?

The time users have to withdraw after an upgrade is announced and before it takes effect. If an upgrade can take effect faster than a withdrawal can complete, users who disagree with it cannot leave first.

### What is a security council?

A multisig, usually of independent signers, that can act quickly in an emergency, for example to pause a bridge or fix a bug. A council that can bypass delays only in emergencies, with a high signing threshold, gives users more assurance than a small team multisig.

### What are rollup stages?

A shorthand the Ethereum community uses for rollup maturity. Stage 0 relies on its operators. Stage 1 has a working proof system with a security council as a backstop. Stage 2 limits the council to provable bugs and gives users time to exit before upgrades. The table shows the contract facts behind those labels.

### Can a sequencer censor my transaction?

It can delay it, but most rollups let users send a transaction through Ethereum that the rollup must include after a set delay. The table shows whether that path exists for each rollup and how long the delay is.

## Glossary

- **Proxy admin**: The account allowed to replace the code behind an upgradeable contract.
- **Security council**: A multisig of independent signers that can act on a rollup's contracts in an emergency.
- **Exit window**: The time between an upgrade becoming known and taking effect, less the time a withdrawal needs.
- **Forced inclusion**: A transaction sent through a rollup's Ethereum contracts that the rollup must include after a set delay, even if its sequencer ignores it.

## Related apps

- [DeFi Admin Keys: Multisig Thresholds and Timelocks](https://voltfincrypto.com/apps/defi-admin-keys-multisig-timelocks)
- [Smart Contract Upgrade Tracker: Proxy and Owner Changes](https://voltfincrypto.com/apps/smart-contract-upgrade-tracker)
- [L2 Withdrawal Times to Ethereum by Rollup](https://voltfincrypto.com/apps/l2-withdrawal-times)
- [Safe Multisig Checker: Owners, Threshold and Modules](https://voltfincrypto.com/apps/safe-multisig-checker)
- [Ethereum Layer 2 List Ranked by Activity, Fees and Value](https://voltfincrypto.com/apps/ethereum-layer-2-list)
- [Ethereum TPS: Mainnet and Layer 2 Transactions per Second](https://voltfincrypto.com/apps/ethereum-tps)

Build it in Voltfin Studio: https://app.voltfincrypto.com/signup?next=%2F