Rethinking Rollups with OpEVM: An Open-Source SDK to Build Optimistic Rollups

Today, the Avail team is open-sourcing a new prototype of the Optimistic Ethereum Virtual Machine (OpEVM) software development kit (SDK). As a promising alternative to traditional smart contract-based rollups, developers can use OpEVM SDK to build sovereign, EVM-compatible optimistic rollups.

By Avail Team 8 min read
Rethinking Rollups with OpEVM: An Open-Source SDK to Build Optimistic Rollups

Today, the Avail team is open-sourcing a new prototype of the Optimistic Ethereum Virtual Machine (OpEVM) software development kit (SDK). As a promising alternative to traditional smart contract-based rollups, developers can use OpEVM to build sovereign, EVM-compatible optimistic rollups. This tech provides developers with a decentralized infrastructure for running a layer-2 (L2) blockchain, that can support a decentralized sequencer set, exists without an enshrined bridge on a layer-1 (L1), and genuinely verifies state transitions optimistically.

OpEVM is built to work atop Avail’s data availability layer, a base layer that is optimized for data availability, leaving transaction executions to separate layers. This means that OpEVM facilitates the creation of rollups that operate independently of smart contracts for dispute resolution. It is this independence from smart contracts that makes OpEVM unique.

OpEVM was built as a collaborative project between Avail, and the Equilibrium Group. This OpEVM prototype has limitations and is not production ready. We invite the rollup and application developer community to contribute and build using OpEVM. See details at the end of this post.

In conventional rollups, smart contracts on the L1 are tasked with handling any disputes that arise within the rollup. Rollups built using OpEVM on the other hand, are self-resolving (more on what that means below).

In this setup, the resolution of disputes is handled within the rollup itself, with the state of the chain determined solely by node operators. This departure from reliance on an execution-capable base layer simplifies the architecture and operation of rollups.

The deliberate design choice of Avail to focus on data availability and not execution brings efficiency to the OpEVM stack. In the OpEVM architecture, Avail serves a critical role as a data availability layer and a source of security for the rollup. This unique setup allows the rollup to inherit the security from Avail's validator set, but still gives them the flexibility to use their native token for liveness and incentivization.

Execution on Base Layer vs No Execution on Base Layer

Rollups on Ethereum

To start, let's explore the workings of traditional Ethereum-based rollups, which are fundamentally centered around the smart contract. In this design, transactions are typically posted to a sequencer who is responsible for ensuring the transactions are posted to a smart contract back on the base layer (e.g. Ethereum). The new state, resulting from the execution of these transactions off-chain, is then optimistically shared across the network. Should any participant contest this state, they submit a fraud proof to the smart contract.

The smart contract here serves an indispensable role, acting as an autonomous arbiter that determines the validity of contested states. It does so by verifying the fraud proof via a dispute resolution process, which provides evidence of a state transition's error. Fraud proofs however can only be submitted during the challenge period.

Challenge periods within this traditional rollup architecture are essential. They serve as a window of time allowing any participant to contest a state by submitting a fraud proof. The duration of these challenge periods is inherently dependent on the censorship resistance and transaction inclusion guarantees provided by the base chain. The challenge period must be long enough to ensure that a valid fraud proof has a high probability of being included in the base layer, even in the face of potential censorship attempts.

Rollups using OpEVM

The traditional rollup model stands in stark contrast with the operation of rollups built using the OpEVM stack on Avail. OpEVM based rollups are self-resolving; they do not need a base layer to arbitrate disputes. The base layer, Avail, to which rollups post data and from which they derive their security, does not execute transactions by design. Avail acts as the source of truth by virtue of being a data availability layer, so that all rollup participants have access to all the rollup data.

In OpEVM-based rollups, the ability to verify fraud proofs is transferred from a central smart contract to each node operating within the rollup. Each node is independently capable of verifying the state of the chain under optimistic assumptions. This decentralization of verification duties eliminates reliance on smart contracts and gives node operators greater control and autonomy. The fork choice rule is not determined by a smart contract on the base chain, but rather through the rollup nodes themselves.

The OpEVM model brings significant improvements in efficiency and scalability of rollups. With the workload of verifying state distributed across multiple nodes, the system is both robust and capable of handling large volumes of transactions.

In essence, the OpEVM model delivers a scalable, efficient, and secure alternative to traditional rollups. It offers a promising vision for the future of rollups, opening up new possibilities for L2 blockchain applications.

Unique Features

A standout feature of the OpEVM stack is its support for a decentralized sequencer set. Traditional rollups typically employ centralized sequencers as of now. In contrast, the OpEVM stack allows for a decentralized set of sequencers to order transactions and add them to blocks. This approach amplifies the liveness, decentralization and censorship-resistant properties of rollups. A PoS based sequencer choosing mechanism ensures fair sequencer selection and slashing in case of bad block generation.

In addition, the OpEVM stack employs a permissionless system where anyone can submit fraud proofs. This model deviates from other fraud-proof secured systems that often necessitate the whitelisting of entities before they can participate in dispute resolution at least in current implementations. The open design of OpEVM promotes inclusivity and transparency, ensuring that the system is accountable to all its users. It also implements slashing in case of incorrect fraud proofs to prevent DoS attack vectors.

Rollups on OpEVM circumvent the need for an enshrined bridge on the base layer. This makes for a powerful, novel construction, as there are few cases of rollups that exist atop a base layer that only handles data availability.

Lastly, while many sovereign rollups today lean toward pessimistic approaches, the OpEVM stack enables developers to construct a rollup that has functional fraud proofs in an optimistic construct. State transitions need not be re-computed, assuming no fraud proofs are presented.

With that said, it’s important to note that OpEVM is a community initiative, not intended to compete with existing rollup solutions. Its primary ambition is to explore and expand the design space for rollups. It is intended to show that optimistic rollups can be constructed without enshrined bridges, while still having a decentralized sequencer set and permissionless watchtowers.

Technical Components of OpEVM

At the heart of the OpEVM stack are various technical components, each playing a key role in ensuring the operation of the system. Here are a few of those components:

  • Bootstrap Sequencer: This component is responsible for bootstrapping the OpEVM. It initializes the necessary parameters, establishes the initial block structure, and sets up the initial state of the system.
  • Sequencer: The Sequencer is the main transaction processor in OpEVM. It receives incoming transactions, orders them, and includes them in the blocks to be added to the blockchain. OpEVM Includes support for a decentralized sequencer set for enhanced liveness and censorship-resistant properties.
  • WatchTower: The WatchTower component is responsible for block validation, fraud-proof generation and propagation. It ensures the integrity of incoming blocks and identifies potential fraud or malicious activities.
  • Staking: The Staking component handles the staking mechanisms within OpEVM. It manages stakeholder addresses, tracks staked amounts, and facilitates dispute resolution processes.
  • Fraud-proof Testing: OpEVM includes a built-in mechanism for testing fraud-proof processing. A "fraud server" within the Sequencer implementation provides an HTTP interface that can be used to trigger a one-time fraud construction into the next produced block. The WatchTower will detect this and produce a fraud-proof block, leading to a dispute resolution process.

For more details on the technical components, check the Github repo here.

Each component in the OpEVM stack is designed to support the creation of sovereign, EVM-compatible rollups that are efficient, scalable, and secure. But what does this mean for the teams and developers looking to build on top of OpEVM? Here’s what teams can expect when they utilize the OpEVM stack.

What can teams expect?

For application teams currently operating on Ethereum, the OpEVM stack offers a potential method to build a chain for your application. App-chains are blockchain applications that function as independent chains. Teams can customize their app-chain to suit their specific use case, optimizing for their needs without being limited by the constraints of a shared blockchain.

OpEVM provides the ability to take your existing code, and deploy it to your own rollup. This gives developers the customizability of running their own rollup without requiring them to spin up their own validator set to do so. In addition, the prototype also supports a native token for the appchain which empowers sequencer set decentralization and incentivizes honest behavior on the rollup. As such, teams can concentrate on the core logic and functionality of their application, while OpEVM takes care of the underlying blockchain infrastructure.

OpEVM enables developers to deploy their existing Solidity code on sovereign chains, which they have full control over without relying on a smart contract. Unlike traditional rollups that depend on a multisig controlled by just a few individuals (introducing centralization concerns) for emergency upgrades, chains built with OpEVM are self-governed. Developers can independently manage their application's rules, data, and functionality, all while maintaining security benefits from the base layer. This also allows for the use of social consensus to hard fork a chain if needed, a feature not typically possible with smart contract-based rollup implementations.

For rollup developers and rollup-as-a-service providers, the OpEVM SDK provides the tools to build self-resolving rollups that operate independently of smart contracts. This drastically simplifies the architecture of rollups and increases their efficiency and opens up a whole new realm of possibilities for service providers, allowing you to offer customers a more scalable, efficient, and secure rollup solution.


In summary, the OpEVM SDK suggests that the current way rollups are built is not the only way rollups can be built. By leveraging Avail as a base layer and employing a unique architecture that enables self-resolving rollups, OpEVM proposes a prototype for an efficient, scalable, and secure model for building optimistic Layer-2 solutions.

OpEVM invites developers and enthusiasts in the broader community to use, contribute to, and enhance the technology. As a prototype, there are many areas for improvements and development. For example, the prototype does not support execution light clients (LC), as it is expensive for LCs to re-execute blocks. However, the design can support validity proofs of correct block execution as fraud proofs which would allow light clients to follow the chain quite easily. Please note that this is not about data availability light clients, which are supported but not yet implemented in the current OpEVM design.

Looking ahead, as the project evolves, our roadmap includes incorporating advancements in Zero-Knowledge (ZK) techniques. In particular, we are considering the use of recursive proofs to simplify the verification process for light clients and full nodes. This will further enhance the efficiency and scalability of OpEVM-based rollups.

As we continue to build and improve this technology, we look forward to seeing the innovative and unique rollups that the community will create.For those interested in diving deeper into the technical details of OpEVM and contributing to the project, we invite you to visit our Github page and check out our demo video.

Thank you for joining us on this journey into the future of optimistic rollups. We can't wait to see what you'll build with OpEVM.