Towards Mainnet Interop: Introducing the Inaugural Unichain and OP Mainnet set
proposal type: informational / discussion
Summary
We, Optimism Foundation and Unichain Foundation are preparing to launch native OP Stack Interoperability on Mainnet with an inaugural set consisting of Unichain and OP Mainnet.
Subject to final technical readiness and governance approval, the two chains will be upgraded into a common Interop set. This will allow transactions on one participating chain to consume and validate messages initiated on another participating chain at the protocol level, without relying on a separate third-party bridge validator set.
The first release will focus on native ETH transfers between Unichain and OP Mainnet. Broader token support, application-level integrations, and the addition of further chains will follow after the initial system has been deployed and proven in production.
This post is intended to:
- Communicate the proposed inaugural chain set;
- Explain why Unichain is a go-to-market strong partner;
- Clarify what is and is not included in the initial release;
- Explain the relationship between upgrade 20, 21 and the subsequent Interop activation upgrade; and
- Invite governance feedback before the executable activation proposal is submitted.
What Interop Changes
Today, OP Stack chains are largely independent execution environments. Applications can communicate across chains, but doing so generally requires a bridge or messaging system with its own contracts, operating model, security assumptions, and confirmation rules.
Interop moves cross-chain message validity into the OP Stack protocol itself.
Chains participating in an interoperability set become aware of one another’s state and message dependencies. Nodes validate whether a message consumed on one chain was validly initiated on another. Relayers may transport the message, but they do not determine whether it is valid: validity is independently checked by the chains.
This creates a foundation for applications to build experiences spanning multiple OP Stack chains while relying on the security model of the participating chains rather than an unrelated bridge committee or external validator network.
The objective is not to erase the differences between chains. It is to let chains remain specialized without forcing users, applications, and liquidity to remain isolated within each chain.
docs: interop explainer, specs.
Why Unichain and OP Mainnet
Unichain
Unichain is a natural participant because its ecosystem is centered on DeFi, trading, and onchain execution.
These activities frequently require capital to move between venues: market makers rebalance inventory, users move assets toward the best execution environment, and applications source liquidity from outside their immediate chain. Faster protocol-native transfers can reduce the operational friction involved in those flows.
Unichain also represents one side of a broader specialization thesis for the network: applications should be able to choose an execution environment optimized for their use case without requiring all users and liquidity to permanently relocate there.
OP Mainnet
OP Mainnet provides the existing economic and governance anchor for the inaugural set. It has a broad application ecosystem, an established asset base, and mature operating infrastructure.
The two chains are not intended to be interchangeable. They bring distinct economic roles:
- Unichain brings a trading- and execution-oriented ecosystem;
- OP Mainnet brings an established application and capital base.
That complementarity makes this a more meaningful initial network than the two chains competing to host identical applications.
Additionally, the initial set of interoperating chains needs to:
- run the standard OP Stack under the Standard Rollup Charter, with upgrades controlled by Optimism Governance and the Security Council;
- run under the same security assumptions on the same contract release and prestate as the other members;
- have an operator team ready to run interop-capable infrastructure and participate in shared incident response;
- bring a genuinely different kind of economic activity, so we are testing real cross-chain demand rather than multiple copies of the same app.
Unichain and OP Mainnet meet all four today as OP Enterprise grade chains. Other chains that meet them are encouraged to join through later proposals.
Initial Launch Scope
The right first release is not the broadest possible release. It is the smallest release that proves the protocol, provides clear user value, and can be operated safely.
Included at Launch
the initial supported scope will include:
- Unichain and OP Mainnet in a Interop dependency set;
- protocol-level validation of cross-chain message dependencies between the two chains;
- a supported path for native ETH transfers between these chains;
- interop-capable node, same security assumptions, monitoring, and operator infrastructure; and
- developer documentation for the initial supported flow.
The underlying Interop protocol is more general than an ETH transfer and supports generic cross domain messages. However, the product and integration surface promoted at launch will intentionally focus on native ETH transfers. This gives users and operators one clear, testable flow while keeping the number of asset contracts, adapters, application integrations, and edge cases manageable.
Not Included at Launch
The initial release is not designed to support:
- generalized ERC20 transfer support for every existing token;
- automatic compatibility for tokens deployed through the existing standard bridge;
- a single unified balance or pool of liquidity across the two chains;
- atomic execution of arbitrary multi-chain application workflows;
- automatic integration by wallets, exchanges, bridges, or DeFi applications;
- interoperability with every OP Stack chain; or
- a guarantee that liquidity fragmentation disappears at activation.
Shared Security and Operational implications
Compared to existing non-native interop solutions, native interop replaces an external bridge trust assumption with deeper protocol coordination. That is a stronger foundation, but it is not free of operational consequences. A cross-chain transaction introduces a dependency between its initiating and executing chains. Nodes must verify that the initiating message exists and remains valid before accepting the transaction that consumes it. The fault-proof and settlement systems must also be able to resolve the relevant state consistently across the set.
The participating chains therefore need:
- compatible governance and upgrade controls;
- aligned fault-proof and settlement configurations;
- coordinated software releases;
- shared monitoring of cross-chain safety and liveness;
- clear procedures for pausing or limiting interop during an incident; and
- a common understanding of how an incident affecting one member can affect cross-chain activity elsewhere in the set.
OP Enterprise provides the operational foundation for the inaugural set, supporting coordinated upgrades, monitoring, and incident response across Unichain and OP Mainnet.
Local transactions that do not depend on another chain remain conceptually distinct from cross-chain transactions. Nevertheless, the activation proposal must clearly describe where risk is shared, what can be isolated, and what actions governance or the security council may take during an incident.
What to expect from the upcoming Upgrades
Interop activation is being separated into preparatory and activation stages.
Upgrade 20 and 21: Preparing the infrastructure for Interop
Upgrades 20 and 21 establish the technical foundations required for Interop, but neither upgrade activates interoperability between chains.
Upgrade 20 introduces super-root dispute games, replacing the existing single-chain output-root format with one designed to eventually support verification of state across multiple chains. Initially, chains will continue to operate and finalize independently.
Upgrade 21 prepares the L1 settlement infrastructure for Interop. It moves each chain’s ETH custody into a dedicated ETHLockbox and introduces the contracts needed to migrate participating chains onto shared settlement and dispute infrastructure. It also improves withdrawal reliability ahead of Ethereum’s upcoming Glamsterdam upgrade.
Following these upgrades, a separate governance proposal will request approval to activate Interop between Unichain and OP Mainnet. This activation will involve a coordinated L2 hard fork, migration to shared L1 infrastructure, and enabling protocol-level cross-chain message validation.
The subsequent Interop activation upgrade
After upgrade 20 and the remaining operational prerequisites have been completed, a separate governance proposal will request approval to activate Interop.
that proposal is expected to include:
- a coordinated L2 hard fork across Unichain and OP Mainnet;
- configuration of the two chains as a shared Interop dependency set;
- activation of protocol-level cross-chain message validation;
- migration of the participating chains to shared L1 settlement and dispute infrastructure;
- migration to a shared ETHLockbox for the participating chains;
- the exact contract implementations and migration calldata;
- the proposed activation timestamp;
- audit and testing results;
- monitoring and incident-response procedures; and
- required actions and release versions for node and chain operators.
Next Steps
This post records the current intention for Unichain and OP Mainnet to form the inaugural Mainnet Interop set, subject to final readiness and the applicable governance approvals.
The Upgrade 20,21 and activation proposal will contain the precise specifics of what each upgrade entails. Interop succeeds when chains can specialize without turning specialization into isolation. Unichain and OP Mainnet provide a credible first network on which to prove that model.