Understanding Rollup Upgradability in 2026

Rollups have become one of the most important parts of how Ethereum handles a large number of transactions. They work by bundling many transactions together, processing them outside the main Ethereum chain, and then sending the results back to Layer 1 for final verification. This approach has helped bring down gas fees and speed up transaction times for millions of users. But rollups are not finished products. They need to be updated, improved, and sometimes completely reworked as the technology around them evolves. That process is what we call rollup upgradability.

Understanding rollup upgradability explained in simple terms is important because every time a rollup gets upgraded, it can affect the security of user funds, the rules of the network, and how much control the community has over the system. As we move into 2026, the conversation around Ethereum rollup upgradability has changed dramatically, especially as more projects focus on stronger governance models and long-term blockchain solutions that reduce upgrade risks. Vitalik Buterin himself has said the old way of thinking about rollups no longer works, and new upgrade paths are being explored. This blog will walk you through everything you need to know about how rollups are upgraded, what the current landscape looks like, and what changes are coming.

What Are Rollups and Why Do They Need Upgrades?

Before we get into the mechanics of rollup upgradability, it helps to understand what rollups actually do. A rollup is a type of Layer 2 solution that processes transactions off the main Ethereum chain but posts transaction data (or proofs of that data) back to Ethereum Layer 1. This way, the rollup gets its security from Ethereum while being able to handle far more transactions than Ethereum can on its own.

There are two main types of rollups that power the Layer 2 ecosystem today.

1. Optimistic Rollups

These assume that all transactions bundled in a batch are valid by default. They only check for errors if someone raises a dispute, which is called a fraud proof. Arbitrum and Optimism are the biggest examples of optimistic rollups. When a user wants to withdraw funds back to Ethereum, they typically have to wait through a challenge period (usually about 7 days) before the withdrawal is finalized.

2. ZK Rollups (Zero Knowledge Rollups)

These take a different approach. Instead of assuming transactions are valid, they generate a mathematical proof (called a validity proof or ZK proof) for every batch. This proof is then verified on Ethereum Layer 1. Because the proof confirms correctness upfront, withdrawals can be processed faster. zkSync, StarkNet, Scroll, and Linea are examples of ZK rollups.

Now, why do rollups need upgrades? There are several reasons. First, rollups are still a young technology. Bugs can exist in the smart contracts that power them, and those bugs need to be fixed. Second, new features need to be added as the ecosystem grows. Third, as Ethereum itself evolves (through upgrades like Fusaka and the upcoming Glamsterdam), rollups need to stay compatible with the base layer. And fourth, the decentralization of rollups is an ongoing process, and governance structures need to be improved over time.

How Rollups Are Upgraded: The Technical Side

The development of Layer 2 rollup upgrades is not as simple as pushing a software update to an app on your phone. Since rollups run on smart contracts deployed on Ethereum, and those smart contracts hold billions of dollars in user funds, the upgrade process has to be handled with extreme care. Here is how the process typically works.

1. The Proxy Contract Pattern

Smart contracts on Ethereum are, by default, immutable. Once you deploy them, the code cannot be changed. But rollups need to be upgraded, so developers use something called the proxy pattern. In this setup, there are two contracts: a proxy contract and a logic (implementation) contract. The proxy contract is the one that users interact with. It holds all the state data and user funds. But when it receives a function call, it forwards that call to the logic contract using a special operation called “delegatecall.” This means the logic contract’s code runs in the context of the proxy, reading and writing to the proxy’s storage.

When an upgrade is needed, developers deploy a new logic contract with the updated code and then point the proxy to this new contract. From the user’s perspective, the address they interact with stays the same, but the underlying logic has changed. This is how most Ethereum rollup upgradability works at the contract level.

2. Multisig Governance

The question of who has the authority to point the proxy to a new logic contract is where governance comes in. In many rollups today, this power is held by a multisig wallet. A multisig is a smart contract wallet that requires multiple signatures (from different people or entities) to execute a transaction. For example, Arbitrum’s Security Council uses a 9 of 12 multisig threshold, meaning 9 out of 12 designated members must approve an upgrade for it to go through.

3. Timelocks and Exit Windows

To protect users from sudden or malicious upgrades, some rollups implement timelocks. A timelock adds a mandatory waiting period between when an upgrade is proposed and when it actually takes effect. During this window, users can review the proposed changes and, if they disagree, withdraw their funds from the rollup before the upgrade happens. This exit window is a core concept in rollup upgradability, explained by the L2BEAT Stages Framework.

4. DAO-Based Governance

Some rollups have moved beyond simple multisig control and implemented full DAO (Decentralized Autonomous Organization) governance. In this model, token holders can propose and vote on upgrades. Arbitrum’s DAO, for example, allows ARB token holders to propose and vote on changes to the protocol. The governance smart contracts are implemented on the Arbitrum One rollup chain itself. A DAO-initiated upgrade on Arbitrum requires multiple delay periods across L2 and L1, with the full process taking about 17 days and 8 hours for upgrades that touch both layers.

5. Security Council Override

Even with DAO governance, most rollups maintain a Security Council that can act quickly in emergencies. On Arbitrum, the Security Council can upgrade contracts without any delay and can also cancel any upgrades initiated by the DAO. This is a necessary safety valve because if a critical bug is discovered, waiting 17 days for a governance vote could lead to massive losses. However, it also means that a compromised Security Council could push through a malicious upgrade instantly.

The L2BEAT Stages Framework: Measuring Rollup Maturity

To help users and developers understand how mature and decentralized a rollup actually is, the L2BEAT team introduced the Stages Framework. This framework was first proposed by Vitalik Buterin on the Ethereum Magicians forum in November 2022 and was later refined into a clear set of requirements by L2BEAT. The framework categorizes rollups into three stages based on how much control operators have over the system versus how much is handled by smart contracts and community governance.

Stage 0: Full Training Wheels

At this stage, the rollup is effectively run by its operators. The team behind the rollup has full control over upgrades, the sequencer, and the bridge contracts. Users are trusting the operators to act honestly. Most rollups are launched at this stage, and a large number of them are still here. According to a research paper published through INRIA in December 2025, across 129 Layer 2 projects tracked by L2BEAT (as of July 2025), instant upgrades without exit windows appear in about 86 percent of projects.

Stage 1: Limited Training Wheels

In this stage, the rollup transitions to being governed more by smart contracts. A fully functional proof system is in place (fraud proofs for optimistic rollups, validity proofs for ZK rollups). Users can exit the system without needing the operator’s cooperation. However, a Security Council still exists to handle bugs and emergencies. For Stage 1, users must have at least 7 days to exit in case of unwanted upgrades initiated by entities outside the Security Council. The Security Council itself can still act quickly on upgrades.

Stage 2: No Training Wheels

This is the final stage where the rollup is fully managed by smart contracts. The fraud-proof or validity proof system is permissionless (anyone can participate). Users get at least 30 days to exit in case of unwanted upgrades. The Security Council can only intervene for bugs that are provably detected on the chain. At this stage, the rollup truly inherits the security properties of Ethereum itself.

As of early 2026, only a handful of rollups have reached Stage 1 (notably Arbitrum, OP Mainnet, and Base), and reaching full Stage 2 remains an ongoing challenge for the entire ecosystem.

Comparison of Rollup Upgrade Governance Models

Rollup	Upgrade Mechanism	Key Characteristics
Arbitrum One	DAO Governance + Security Council (9/12 multisig)	DAO upgrades take about 17 days 8 hours total delay; Security Council can upgrade instantly; Stage 1 rollup
Base (OP Stack)	Nested 2/2 Multisig with Security Council	Requires approval from 3 parties (Base multisig, OP Foundation, Security Council); contracts instantly upgradable; Stage 1 rollup
zkSync Era	ZKsync Security Council + Community Governance (ZIPs)	V29 upgrade passed governance vote; supports modular settlement and upgradable ValidatorTimelock; audited by OpenZeppelin
Linea	Centralized team control with timelock (currently 0s delay)	No exit window for unwanted upgrades; contracts instantly upgradable; whitelisted proposers; Stage 0 rollup
Sovereign Rollups (e.g., on Celestia)	Fork-based upgrades (like L1 blockchains)	Nodes choose whether to accept upgrades; no multisig control; the community can stay on old software if they disagree

Ethereum’s Base Layer Upgrades and Their Impact on Rollups

The story of rollup upgradability cannot be told without talking about what is happening on Ethereum’s base layer. Every time Ethereum goes through a major upgrade, rollups need to respond. Sometimes they need to add support for new features. Other times, the Ethereum upgrade directly changes how rollups operate or how much data they can post.

1. The Fusaka Upgrade (December 2025)

The Fusaka upgrade shipped on December 3, 2025, and was one of the most important upgrades for the rollup ecosystem. It introduced PeerDAS (Peer to Peer Data Availability Sampling), which allows nodes to verify data availability without downloading every single blob of data. This is a big deal because it means Ethereum can support more blob data (which rollups use to post their transaction data) without putting too much burden on individual nodes. The upgrade also introduced Blob Parameter Only (BPO) forks, which allow the blob count to be increased between major upgrades without needing a full hard fork.

For rollups, Fusaka meant that the cost of posting data to Ethereum dropped further, and the capacity for how much data could be posted in each block increased. This directly benefits users because lower data costs translate to lower transaction fees on Layer 2.

2. The Glamsterdam Upgrade (Expected First Half 2026)

Ethereum’s next major upgrade is Glamsterdam, planned for the first half of 2026. This upgrade is expected to include enshrined Proposer Builder Separation (ePBS) and Block Level Access Lists (BALs). ePBS will change how Ethereum blocks are built and proposed, which could affect how rollup sequencers interact with the base layer. BALs will optimize how nodes access contract storage data, reducing redundant reads and lowering gas costs for complex smart contract operations.

3. The Hegota Upgrade (Expected Second Half 2026)

Later in 2026, the Hegota upgrade will focus on integrating Verkle Trees, which improve how Ethereum manages its state data. This will make running an Ethereum node lighter and more accessible, which benefits the entire ecosystem, including rollups that rely on Ethereum for security.

Each of these Ethereum upgrades creates a ripple effect. When Ethereum changes its gas pricing, rollups need to update their fee models. When Ethereum increases blob capacity, rollups need to adjust their data posting strategies. When new EVM opcodes are added, rollups need to ensure their execution environments support them. This is why Layer 2 rollup upgrades are an ongoing process, not a one-time event.

Vitalik Buterin’s New Vision: Why the Old Rollup Model Is Changing

In February 2026, Ethereum co-founder Vitalik Buterin made a statement that shook the entire Layer 2 community. He declared that the original rollup-centric roadmap, which positioned Layer 2 networks as the primary way Ethereum would scale, no longer makes sense.

Buterin pointed to two major reasons for this shift.

First, the progress of Layer 2 networks toward full decentralization has been far slower and more difficult than originally expected. The rollup-centric roadmap assumed that L2s would quickly move through the Stages Framework and become fully trustless extensions of Ethereum. In reality, most rollups are still at Stage 0, and some L2 operators have explicitly stated they may never progress beyond Stage 1 due to technical difficulties with ZK EVM safety or regulatory requirements for maintaining control.

Second, Ethereum Layer 1 itself has scaled much faster than anyone anticipated. After the Pectra and Fusaka upgrades, fees on Ethereum’s base layer have remained low, and gas limits are expected to increase further in 2026. This means the original assumption that L1 would be too expensive for most users is no longer true.

Buterin was very direct about what this means for L2 networks. He wrote: “If you create a 10,000 TPS EVM where its connection to L1 is mediated by a multisig bridge, then you are not scaling Ethereum.” He argued that scaling Ethereum should mean creating large quantities of block space that is backed by the full security of Ethereum, where activity is guaranteed to be valid, uncensored, and untouched as long as Ethereum itself functions.

Instead of abandoning Layer 2s entirely, Buterin proposed viewing them as a spectrum of networks with different levels of connection to Ethereum. He encouraged L2 teams to find value beyond just scaling, such as privacy features, specialized non-EVM virtual machines, ultra-low latency, or application-specific designs. He also stressed the importance of a native rollup precompile on Ethereum that would use built-in ZK EVM proofs to enable trustless verification of L2 state without needing Security Councils.

The Risks of Rollup Upgradability

Every upgrade to a rollup carries risk, and understanding these risks is essential for anyone using or building on Layer 2 networks. Here are the main concerns that come with how rollups are upgraded today.

1. Malicious Upgrades

If the entity controlling the upgrade keys (whether a multisig, Security Council, or single admin) is compromised, they could push through a malicious upgrade that drains user funds. Since the proxy contract holds all state and assets, changing the logic contract to a malicious one could give attackers access to everything. This is not just theoretical. The INRIA research paper found that in about 86 percent of L2 projects, contracts can be upgraded instantly without any exit window for users.

2. Storage Collision Bugs

The proxy pattern requires careful management of storage layouts. If a new logic contract changes how storage variables are ordered, it can lead to storage collisions where the contract reads the wrong data. The Audius governance hack is a well-known example of this, where a storage collision in the proxy contract allowed an attacker to reinitialize the governance and steal treasury funds.

3. Centralization Risk

Even rollups with DAO governance often have a Security Council that can override the DAO and push instant upgrades. While this is necessary for emergency bug fixes, it concentrates enormous power in a small group of people. If 75 percent or more of the Security Council is compromised, they could potentially push through any upgrade they want.

4. User Exit Window Problems

For exit windows to actually protect users, users need to be aware of proposed upgrades and have the technical ability to withdraw in time. In practice, most users do not monitor governance proposals, and the withdrawal process from some rollups can take days (especially from optimistic rollups, where the challenge period adds delay). If a withdrawal delay reduces the effective exit window to less than the minimum required time, the protection becomes meaningless.

5. Compatibility with Ethereum Upgrades

When Ethereum undergoes a hard fork, rollups must upgrade their systems to remain compatible. If a rollup team is slow to adapt, or if the upgrade introduces unexpected interactions with the rollup’s smart contracts, it can create vulnerabilities or downtime. Arbitrum’s upgrade to ArbOS 51 with Fusaka EVM support is an example of how rollups must proactively prepare for Ethereum base layer changes.

L2BEAT Stages Framework: Requirements at Each Stage

Requirement	Stage 0	Stage 1	Stage 2
Proof System	Not required to be functional	Fully functional proof system in place	Permissionless proof system (anyone can participate)
User Exit Window	No minimum exit window required	At least 7 days for non-Security Council upgrades	At least 30 days for all upgrades, including DAO-initiated
Security Council Power	Full control over upgrades	Can act quickly but must be sufficiently decentralized (8+ members, 75%+ threshold)	Restricted to responding only to on-chain detected bugs
User Independence	Users depend on operators	Users can exit without operator cooperation	Users are fully protected from governance attacks
State Reconstruction	Open source software is available to reconstruct the state from L1 data	Same as Stage 0	Same as Stage 0 and Stage 1

Sovereign Rollups vs Smart Contract Rollups: Different Upgrade Paths

Not all rollups handle upgrades the same way. There is an important distinction between smart contract rollups (like those on Ethereum) and sovereign rollups (like those being built on Celestia).

Smart contract rollups depend on contracts deployed on a settlement layer (like Ethereum) for their upgrades. Changing the rollup means changing those smart contracts, which usually requires a multisig or governance process. The rollup is bound by the social consensus and rules of the settlement layer.

Sovereign rollups take a completely different approach. They upgrade through forks, just like Layer 1 blockchains. New software versions are published, and node operators choose whether to update. If some nodes disagree with the upgrade, they can stay on the old software. This gives the community more direct control over upgrades, and no single entity can force an upgrade on everyone. The trade-off is that sovereign rollups do not inherit the same level of settlement security from a base layer like Ethereum.

Both approaches have their strengths. Smart contract rollups benefit from Ethereum’s strong security guarantees, but they introduce governance complexity and centralization risks around upgrade keys. Sovereign rollups give more power to the community but require the community to actively run nodes and participate in governance decisions.

What to Expect From Rollup Upgradability in 2026

The year 2026 is shaping up to be a turning point for how rollups are upgraded and how their role in the Ethereum ecosystem is understood. Here are the key developments to watch.

1. Push Toward Stage 1 as the Minimum Standard

Vitalik Buterin has stated clearly that rollups should reach Stage 1 at a minimum. L2s that remain at Stage 0 with centralized control mechanisms risk being viewed not as Ethereum extensions but as independent L1 networks with bridges. This creates social and economic pressure for rollup teams to decentralize their upgrade processes, implement proper exit windows, and deploy functional proof systems.

2. Native Rollup Precompile on Ethereum

One of the most exciting developments is the proposed native rollup precompile. This would be a built-in function on Ethereum that verifies EVM execution using ZK proofs. If a rollup uses the standard EVM, it could rely on this precompile for verification instead of maintaining its own proof system and Security Council. The precompile would auto upgrade along with Ethereum, meaning the rollup would always be compatible with the latest version of the EVM without needing its own upgrade process for the verification layer.

3. Increased Blob Capacity and BPO Forks

The Blob Parameter Only fork mechanism introduced with Fusaka means that blob throughput can be increased without waiting for a full hard fork. Developers have agreed to implement increases in blob targets (from the current levels toward higher numbers), which will continue to lower data posting costs for rollups. This ongoing capacity expansion will require rollups to update their data submission logic and fee models accordingly.

4. L2 Specialization Beyond Scaling

With Ethereum L1 becoming cheaper and more capable, rollups that only offer basic scaling will struggle to justify their existence. We can expect rollup teams to differentiate through privacy features, non-EVM execution environments, application-specific designs (like gaming or social platforms), and ultra-low latency for financial applications. Each of these specializations will require its own set of upgrades and development paths.

5. Cross-Chain Interoperability Upgrades

The ZKsync protocol’s V29 upgrade introduced native interoperability messaging between ZK Chains through the ZK Gateway, allowing chains to communicate using Merkle proofs and a shared root structure. The Optimism Superchain is also working on cross-chain messaging through its Upgrade 16 initiative. These interoperability features will require ongoing upgrades to both the rollup contracts and the base layer infrastructure.

6. Formal Verification of Rollup Mechanisms

As rollups secure larger amounts of value, the need for mathematical guarantees about their correctness grows. Projects like Nethermind’s Halva framework are already applying formal verification to ZK circuits, and a critical bug was discovered in Scroll’s Keccak 256 circuit through this process. Expect more rollup teams to invest in formal verification as part of their upgrade and development workflows.

Layer 2 Blockchain Development in the Real World

The following projects reflect how Layer 2 architecture and rollup technology are already being applied across AI computing and blockchain infrastructure. Each implementation showcases the same distributed infrastructure principles discussed throughout this article, from node-based participation and token governance to upgradable smart contracts and community-driven scaling.

Conclusion

Rollup upgradability is one of the most important and least understood topics in blockchain today. Every time a rollup is upgraded, it touches on deep questions about security, decentralization, governance, and user trust. The proxy pattern allows smart contracts to be updated, but it also introduces risks around storage collisions, centralization of upgrade authority, and the possibility of malicious changes. The L2BEAT Stages Framework gives us a clear way to measure how mature a rollup’s upgrade process actually is, from Stage 0, where operators have full control, to Stage 2 where smart contracts and community governance run everything.

As we move through 2026, the landscape is shifting rapidly. Vitalik Buterin’s declaration that the rollup-centric roadmap no longer makes sense marks a turning point in how we think about Layer 2’s role in the Ethereum ecosystem. With Ethereum Layer 1 scaling through upgrades like Fusaka, Glamsterdam, and Hegota, rollups are no longer the only answer to Ethereum’s capacity challenges. Instead, they are evolving into specialized networks that offer unique features beyond basic transaction processing.

For users, understanding rollup upgradability explained in practical terms means knowing who controls your rollup’s upgrade keys, how much time you have to exit if an unwanted upgrade happens, and what stage of decentralization the rollup has reached. For developers and businesses, it means designing upgrade mechanisms that balance the need for quick bug fixes with the principle of giving users meaningful control over their assets. The future of Layer 2 rollup upgrades will be shaped by native ZK EVM precompiles, improved interoperability standards, formal verification, and a new understanding that rollups must earn their place in the Ethereum ecosystem through genuine decentralization and unique value.