🎉 We are deprecating the Optimism SDK and migrating all tutorials to use viem/op-stack. Read more →
OP Stack
Interoperability
Interop explainer
Interop is currently in active development and not yet ready for production use. The information provided here may change frequently.

We recommend checking back regularly for the most up-to-date information.

Interoperability explainer

The Oracle problem states that a blockchain can only be certain about information generated by that chain. But what about information that happens outside that blockchain, how do you verify what happens somewhere else?

Interoperability is the ability for a blockchain to securely read the state of another blockchain. Native OP Stack interoperability provides the ability to read messages and transfer assets across chains in the Superchain (without having to go through L1) via low-latency, secure message passing. This results in the following benefits:

  • 1-block latency asset movement that is both maximally capital efficient and non-fragmenting
  • improved user experience for developers on the Superchain
  • secure transfer of ETH and ERC-20s across L2s
  • horizontally scalable applications

In a practical sense, this allows users to securely and easily move ETH and tokens from one OP Stack chain to another by leveraging OP governed blockspace security.

Secure message passing

Superchain interop includes both the protocol layer message passing and the Superchain ERC20 token specification.

  • Message passing protocol: the initial + finalizing/executing message that fire events to be consumed by the chains in the dependency set (opens in a new tab)
  • SuperchainERC20 token specification: the SuperchainERC20 turns message passing into asset transfer between chains in the interop set. Learn more about how the SuperchainERC20 token standard enables asset interoperability in the Superchain here

This means ETH and ERC-20s can seamlessly and securely move across L2s, and intent-based protocols (i.e., bridges) can build better experiences on top of the message passing protocol.

Low latency

Interoperability allows for horizontally scalable blockchains, a key feature of the Superchain. With Superchain interop, latency can be 1-block (~2 seconds) by optimistically accepting cross-chain messages.

Interop clusters

The interop protocol works via a dependency set which is configured on a per-chain basis. The dependency set defines the set of chains that a chain will accept incoming messages from.

This gives the OP Stack an unopinionated and flexible foundation, so chain operators can choose which chains their chains depend on, and it is not a requirement that chains are in each other's dependency set.

Superchain interop cluster

The Superchain builds on top of the interop protocol and implements a single mesh network with complete dependencies. In this model, each blockchain in the Superchain interop cluster would have direct connections to every other blockchain, creating a fully connected mesh network. Compared to a hub and spoke model, this provides the highest level of interoperability, as any blockchain can transact directly with any other.

Each blockchain in the Superchain interop cluster shares the same security model to mitigate the weakest-link scenario. As outlined in the Standard Rollup Charter (opens in a new tab), these chains share the same L1 ProxyAdmin Owner. Any changes to the Superchain interop cluster must follow the standard Protocol Upgrade vote procedure—the established governance process for Superchain modifications.

New predeploys

The following predeploys have been added to enable interoperability. Predeployed smart contracts exist at predetermined addresses in the genesis state. They are similar to precompiles but instead run directly in the EVM instead of running native code outside the EVM.

CrossL2Inbox

The CrossL2Inbox is the system predeploy for cross chain messaging. Anyone can trigger the execution or validation of cross chain messages, on behalf of any user.

L2ToL2CrossDomainMessenger

The L2ToL2CrossDomainMessenger is a higher level abstraction on top of the CrossL2Inbox that provides general message passing, utilized for secure transfers ERC20 tokens between L2 chains. Messages sent through the L2ToL2CrossDomainMessenger on the source chain receive both replay protection and domain binding, ie the executing transaction can only be valid on a single chain.

OptimismSuperchainERC20Factory

The OptimismSuperchainERC20Factory creates ERC20 contracts that implement the SuperchainERC20 standard, grants mint-burn rights to the L2StandardBridge (OptimismSuperchainERC20), and includes a remoteToken variable. These ERC20s are called OptimismSuperchainERC20 and can be converted back and forth with OptimismMintableERC20 tokens. The goal of the OptimismSuperchainERC20 is to extend functionalities of the OptimismMintableERC20 so that they are interop compatible.

BeaconContract

The BeaconContract predeploy gets called by the OptimismSuperchainERC20 BeaconProxies deployed by the SuperchainERC20Factory. The Beacon Contract implements the interface defined in EIP-1967 (opens in a new tab).

SuperchainERC20Bridge

The SuperchainERC20Bridge is an abstraction on top of the L2toL2CrossDomainMessenger that facilitates token bridging using interop. It has mint and burn rights over SuperchainERC20 tokens, as described in the token bridging spec (opens in a new tab).

Considerations

Chain operators will need to run additional infrastructure to be part of the interoperable set.

  • The Superchain-backend service, op-supervisor, will be a requirement for running an OP Stack chain that has interop enabled. op-supervisor is responsible for validating all cross-chain messages and will need to have an RPC configured for each chain in the dependency set.
  • In the future, to reduce infrastructure costs, op-supervisor will rely on the P2P network and cryptographic schemes for validating cross-chain messages.

For additional considerations, join the Interop discussion (opens in a new tab) in our specs repo.

Next steps

FAQs

What is the latency/security tradeoff?

If a sequencer does not want to trust another sequencer at all, they can choose to only accept executing messages where the initiating message has been finalized with L1 levels of security. This demonstrates the difference in latency vs speed. The L2 data must be submitted to L1 and then the L1 block containing the transaction with the L2 data must be finalized. It takes about 15 minutes for an L1 block to finalize, and higher throughput OP Stack chains like Base and OP Mainnet submit a batch about every 5 minutes. This means that it could take about 20 minutes for an L2 transaction to be considered final and be able to be trustlessly consumed by another chain. At lower latencies, the sequencer accepting the executing message takes on some amount of equivocation risk. It could be possible to build a bonding system to add economic security to prevent equivocation, but that is not in the scope of the first release.

See this dune dashboard (opens in a new tab) to see how often OP Stack chains submit batches.


Safe and Unsafe Security Diagram

What is stopping a sequencer from censoring a cross-chain message?

There is nothing stopping a sequencer from censoring a transaction when it is sent directly to the sequencer. This does not mean the network has no censorship resistance, users can always send a deposit transaction for censorship resistance as strong as L1 guarantees. The tradeoff here is the latency, instead of being confirmed in ~2 seconds, the transaction can be confirmed at the rate of L1 block production. It may be possible to adopt something like EIP-7547 (opens in a new tab) in the future to enable low latency censorship resistance.

What is the weakest link scenario?

Without shared security, there is a risk that interacting chains could enter a conflicting state due to cross-chain interactions. If a weaker chain in the network is attacked or experiences a reorganization, it could change its state independently. This would leave the entire interop cluster in an inconsistent state, as the security of interactions across chains is only as strong as the weakest chain.

Are callback style transactions possible?

If two blocks are being built at the same time with shared knowledge of their contents, it is possible to build blocks where a transaction calls to another chain, does compute and then a transaction calls back with the results. This requires no protocol level changes, it just requires more sophisticated block builder infrastructure.

What is stopping a shared sequencer from including just the executing message and not the initiating message?

The protocol enforces the fact that all executing messages are valid. It does this by reorganizing out executing messages that have invalid initiating messages. Running software that does not enforce this would be non-standard behavior and would leave yourself at risk of accepting an invalid executing message and therefore running on a forked chain.

What is the trust/verification model? Do sequencers that opt into this interop system have to trust each other fully?

Sequencers only have to trust each other, if they are accepting executing messages where the initiating message is unsafe. This is because the sequencer's ability to equivocate on unsafe data, i.e., batch submit something different from what they gossip over the p2p network. Once data is submitted to L1, it is considered final relative to the L2 and therefore there is no longer an equivocation risk.

Is interop different between chains with non-fungible blockspace?

Chains that have non-fungible blockspace are chains that have different features - it could be that they use Plasma for data availability, a custom gas paying token or have a large execution gas limit. As long as the chain can be fault proven, it can work with Superchain interoperability. At the application layer, it is important for chains to have legibility into the type of chain that the message originated from. This ensures that applications do not accept messages from chains they consider not secure enough. See this discussion (opens in a new tab) for additional thoughts.

When it comes to chains that have different gas limits that are interoperable, it creates a set of transactions that can execute on one chain but not the other. This happens when the transaction consumes more than the gas limit of the smaller chain but less than of the bigger chain. At 2024 usages levels, these sorts of transactions are very rare. In the future, it may be the case that these transactions become more common, it will be up to the chain operators to ensure quality of service for their users.