Reactive Network is getting a new engine. We're calling this the Omni fork. The consensus layer, the developer experience, and the way reactive contracts work are all being rebuilt. This document covers the technical specifics: what's changing, what stays the same, and what it means if you're building on Reactive today or planning to.

The short version: Reactive remains a fully EVM-compatible chain. Your existing contracts keep working. But the infrastructure underneath is being replaced with something faster, simpler, and significantly easier to build on.

Geth+Prysm out, CometBFT in

Reactive Network's Legacy architecture runs on an Ethereum-style consensus stack (Geth+Prysm).  We're replacing the consensus layer with CometBFT, the engine behind most Cosmos ecosystem chains, while preserving full EVM compatibility. Solidity contracts, Ethereum tooling, familiar development workflows – all unchanged. CometBFT handles how the network reaches agreement on blocks; everything else stays the same.

Three things improve immediately.

Instant finality. On Geth+Prysm, reorganizations can happen: a confirmed block gets replaced by a competing one. For Reactive, that's a structural problem, not just a nuisance. A callback sent to a destination chain like Base could be triggered by a transaction that later gets reorged away, leaving an action on one chain caused by something that no longer exists on another. CometBFT eliminates this. Once a block is validated, it's final.

Faster blocks. Block time drops from roughly 7 seconds to approximately 1 second. Callbacks trigger sooner, cross-chain workflows complete faster, and overall network responsiveness improves significantly.

Architectural flexibility. CometBFT's hook-based design lets us implement Reactive's event-listening primitives directly at the consensus layer, rather than working around limitations in infrastructure that wasn't designed for this use case.

Finality in the New Architecture 

There are two kinds of finality that matter for Reactive, and they work differently.

Reactive finality is what CometBFT gives us. Once Reactive Network validates a block, that block is permanent. No reorgs, no competing forks. This is a direct upgrade from Geth+Prysm, where reorgs could and did happen.

Origin finality is about the chains Reactive listens to. When Reactive's Sequencer observes an event on, say, Ethereum mainnet, it treats that observation as canonical. If Ethereum later rolls back the block containing that event and replaces it with a different one, the sequencer doesn't retroactively invalidate its earlier observation. Its position is: "I witnessed both. Both are real from my perspective".

This model carries over unchanged from the current system. The sequencer has always worked this way, and it will continue to. In later phases we may explore decentralizing the sequencer, but the main principle remains: once the network agrees it has observed an event, that observation is final.

No More Dual Deployments

This is the change that developers will feel most directly, and it's a significant simplification.

Under the Legacy architecture, writing a reactive contract means deploying to two separate environments: the RVM (ReactVM) and the top-level Reactive Network (RNK). Your contract logic splits across both, with state living in two places and callbacks routing between them. If that sounds cumbersome, it is. It's been the single steepest barrier to entry for developers who want to build reactive applications.

Under the Omni fork, the RVM is gone. Reactive contracts deploy to a single environment: Reactive Network. There's no dual state to manage, no separate RVM-side initialization, no callbacks from RVM back to RNK. One contract, one deployment, one mental model.

For anyone who's written a standard Solidity contract, the new reactive contract experience should feel immediately familiar. You're writing a smart contract that happens to have event-listening superpowers, not learning a parallel deployment model on top of everything else.

Developer Tooling 

The RVM removal has a ripple effect across the entire developer toolchain, and it's almost entirely positive.

Previously, we provided custom RPC methods to emulate transactions inside the RVM and inspect traces. In practice, these were clunky. They didn't work with mainstream smart contract tooling and required everything to be done manually. That friction is eliminated. With reactive contracts living in standard EVM, every major development tool works out of the box: Hardhat, Foundry, Remix, whatever your team already uses.

The block explorer story gets simpler too. Reactscan no longer needs to reconcile separate transaction and block views across RVM and Reactive Network. Data on Reactscan will look the same as on any other EVM chain, and developers can use familiar tools like Blockscout and Foundry's `cast` to inspect on-chain state.

Subscriptions and Callbacks

If you have existing reactive contracts, here's what you need to know.

Subscriptions keep the same format. New contracts will register them through a new system contract, but the call signature is identical. If you know how to set up subscriptions today, you know how to set them up tomorrow.

Callbacks in the old format will be supported indefinitely. Your existing contracts won't break. The difference in the new model is that emitting a callback no longer routes through the RVM. It happens directly on Reactive Network. For new contracts, instead of emitting a raw event, you can simply call the appropriate method on the system contract. Under the hood it still emits an event, but the developer-facing experience is more intuitive: you call a contract, it handles the rest.

Callback delivery to destination chains works the same way it does today. Reactive Signer posts transactions to the destination network, where they pass through a callback proxy. No changes there.

Destination callback reverts are unchanged as well. If a callback reverts on the destination chain, handling that remains the recipient's responsibility, same as before.

Gas and Payment Models

At launch, the gas model is unchanged. Everything works the way it does now. But with the RVM removed and new system and proxy contracts in place, we can iterate on payment models in ways that weren't practical before.

We're working on new callback payment options. For example, a developer could tell the system contract: "I want to pay for the destination-chain callback upfront, query the oracle for the cost, and settle now". Alternatively, callbacks could be paid for using REACT directly. That second option introduces some complexity around price volatility between payment and execution, so we'll need to address the security implications before shipping it, likely through some form of pre-payment mechanism.

These new payment models will roll out gradually. The current gas model will remain available for the foreseeable future. Nothing is being taken away; options are being added.

EVM Compatibility

Reactive Network will be fully EVM-compatible, targeting Solidity 0.8.29. Contracts compiled with earlier Solidity versions should work as expected. All custom precompiles are being removed. From an opcode perspective, Reactive will be a standard EVM chain. The only precompiles that remain are internal to the system contracts, and developers won't encounter them under normal circumstances.

This is a deliberate move toward convention. Previously, contracts had to be written in somewhat counter-intuitive ways to function as reactive contracts. That's no longer the case. Standard Ethereum smart contracts without any reactive features deploy and run without modification. If you can deploy a Uniswap pool on Ethereum, you can deploy it on Reactive, no changes required.

State During the Transition

Everything carries over. All existing state, account balances, deployed contracts, contract storage, from Legacy to the Omni fork intact. There is no new token, no swap, no claim process.

During the transition itself, there will be a brief disruption on the order of minutes. Our goal is zero lost callbacks: any callbacks arriving during that window should not be lost, only delayed.

What Remains Unchanged 

It's worth being explicit about what stays the same, since not everything is being rebuilt.

Subscription formats remain identical. Callback delivery mechanics are unchanged. The gas model persists at launch. Old reactive contracts continue operating as expected. Destination callback revert handling stays the recipient's responsibility. There are no limits on subscriptions per contract. Payload size limits continue to be determined by the destination network.

The changes are significant, but they're concentrated in the consensus layer and the developer-facing architecture. If you're a user or a contract that just consumes Reactive's capabilities, the transition should be largely invisible.

Looking Ahead 

The immediate priority is completing the CometBFT integration with the EVM execution layer and finalizing the new system contracts that replace the RVM. Everything else depends on this.

From there, full testnet rehearsals using production state to verify that all existing contracts, balances, and storage carry over correctly. Once the testnet is stable and the tooling has been independently audited, we move to mainnet cutover: Legacy's state gets packaged into the genesis of the Omni fork chain, so Reactive continues from where it left off.

After mainnet, newer callback payment models, potential Sequencer decentralization, and expanded callback configuration options become active areas of development, rolled out incrementally as each component is ready.

If you're building on Reactive and have questions about how any of this affects your contracts, reach out. We'd rather address concerns early than have them surface during the transition.

About Reactive Network

Reactive Network is an EVM automation layer built around reactive contracts, event-driven smart contracts for cross-chain, on-chain automation. It runs on CometBFT consensus, providing instant finality and roughly 1-second block times while maintaining full EVM compatibility.

Reactive contracts subscribe to event logs across EVM chains and execute Solidity logic automatically when matching events occur, deciding autonomously when to send cross-chain callback transactions. This model supports conditional cross-chain state changes and continuous cross-chain workflows.

Website | Blog | X | Telegram | Discord | Docs

Build once — react everywhere!