Native interoperability

This page describes native interoperability between two LinethLineth (Formerly the Linea Stack) The open-source ZK-rollup stack, codebase, and technical protocol that's the foundation of Linea Mainnet. Operators can deploy this stack to launch their own Ethereum-compatible L2 or L3 networks. networks. Native interoperability is enabled via the Cross Ledger Interoperability Protocol (CLIP). Each network's operator runs the CLIP plugin in their Lineth node and uses it to coordinate a cross-chain call. There is no shared chain and no third-party bridge operator.

Lineth for institutions

CLIP is a feature provided by Consensys for institutional and enterprise Lineth deployments. To request access, submit a strategic inquiry.

Other interoperability flows

Native interoperability refers to communication between two Lineth networks. To communicate with a Lineth network's finalization layerFinalization layer The blockchain where a Lineth deployment submits proofs and state commitments for verification and hard finality. If the finalization layer is Ethereum (an L1), the deployment is an L2. If the finalization layer is Linea (an L2), the deployment is an L3., use the canonical bridge. To communicate with a non-Lineth network, use a bridge or relayer such as Chainlink CCIP.

Native interoperability flow

Two Lineth networks use CLIP to communicate with each other as follows:

1. Operators of each network configure role-based access control (RBAC) permissions for their network, if required. They onboard organizations, groups, and users; and register the contracts those groups may use.
2. Each operator enables the CLIP plugin on their Lineth node, deploys and registers the contracts it requires, and connects it to the peer network's node.
3. If their network is restricted (access controlled), each operator configures the plugin with the address of their access control endpoint, so it can ask the endpoint to evaluate the permissions of inbound cross-chain calls.
4. A user (or contract) from one network initiates a cross-chain call to the other network.
5. The two networks run a two-phase commit: prepare, then commit or abort. In the prepare phase, they simulate the call until both sides agree on the same result.
6. In the commit phase, both sides commit. If the destination is restricted, it first asks its access control endpoint whether that agreed call would be allowed as a live RPC request. The endpoint evaluates that caller against the destination's own RBAC policy. The subject is the source contract on the source chain, represented as a chain-based decentralized identifier (DID) such as did:pkh:eip155:<source-chain>:<address>; it is not tx.origin of the source transaction. If the endpoint denies the call, or if the endpoint is unreachable, both sides abort instead.
7. If the destination is restricted, its access control endpoint records the decision on its append-only access log.

Known limitation

Currently, the access control endpoint only evaluates the root cross-chain call; nested calls made during execution on the destination are not separately evaluated.

Trust assumptions

Each side checks that it included the agreed call and that both plugins computed the same result from the exchanged simulation. There is no shared proof across the two Lineth networks that replaces trust in the peer operator and the peer endpoints you configured.

See also

• Access control: The access control stack for restricted deployments.
• Canonical bridge: Canonical message service and token bridge to the finalization layer.