6 MIN5 AUG 2026

Interzone Bridging: Moving Value Between Zones on Logos

How Logos Zones move tokens and messages between each other without a trusted intermediary.

Dr. Corey Petty

Interzone bridging makes Logos Zones interoperable and links them to the shared, decentralised base layer.

Bridges have been the most expensive thing in this industry to get wrong. Ronin lost roughly $620 million in March 2022 when five of its nine validator keys were compromised. Wormhole had lost $325 million seven weeks earlier to a signature verification flaw. Harmony's Horizon bridge lost close to $100 million on a two-of-five multisig that summer, Nomad around $190 million a month after that, and Multichain about $126 million in 2023 after its team lost access to the keys holding the pools. Cumulative losses across cross-chain bridges run into the billions.

The causes differ in the detail, but the underlying challenge is the same. Something has to stand between two chains and attest that a deposit happened on the far side, and that something — a relayer, a multisig committee, an MPC keyset — becomes the most valuable target in the system. Compromise the attestor and you are able to mint whatever you like.

Whether it is a cross-chain bridge or a cross-Zone transfer, this mechanism extends the supply chain of a transaction and consequently its privacy exposure surface. Conventional cross-chain bridges mitigate this exposure by inserting a party that both chains agree to believe, but protection is only ever as strong as its weakest link. In nearly every bridge that has been drained, that trusted party was exploited.

So now that Logos Zones can move tokens and messages between one another, the obvious question is: how does that work without a trusted intermediary?

What shipped

PR #542 landed on 11 July: asynchronous cross-Zone messaging between Logos Execution Zone (LEZ) instances, with two demos running on one shared messaging spine. The first is a minimal ping between Zones. The second locks tokens on Zone A and mints a wrapped representation on Zone B. There is also a two-Zone chat app that sends messages across and displays send, finalise and receive timings live in the browser.

This work is called “interzone bridging", but the mechanics have little in common with what bridging between different blockchains normally means. Here, it refers not to moving tokens between different networks, but different Zones that are designed to be interoperable and linked to the Logos base layer.

The shared base layer

Zones are customisable execution environments that lean on the Logos blockchain for consensus and data availability. The documentation covers what a Zone is and how Mantle channels anchor Zone state to the chain. A key property of this architecture is that every Zone reads the same finalised blocks.

Traditional bridges connect chains that share nothing. Ethereum has no idea what Solana’s state is, so somebody has to carry the news across, and that somebody has to be trusted. Every bridge design is some flavor of “who carries the news and why do we believe them.” Multisigs, oracle networks, light clients, they’re all answers to that question, and the first two have been the most expensive answers in the history of this industry.

Logos Zones never face that question. Zone B does not need to be told what happened on Zone A, because Zone A's activity is already sitting in a finalised block that Zone B reads as a matter of course.

How a message moves

The token bridge demo below shows the flow most clearly.

A program on Zone A locks the tokens and records an outbound message through a built-in outbox program. That message lands in a finalised block like any other Zone A activity.
Zone B's sequencer runs a watcher over Zone A's finalised blocks. When the outbound message appears, the sequencer injects the delivery into Zone B as a sequencer-origin transaction, and the wrapped-token program mints.
Zone B's indexer then re-derives that same delivery from the same finalised block, independently. Both Zones run identical LEZ code, so the indexer can reconstruct what the delivery must be, byte for byte, and throw out anything that does not match. Forged deliveries fail. Replayed deliveries fail. The verifier pins Zone A's block-signing keys, so a fabricated source chain fails too.

This means the sequencer injecting the delivery is never trusted. It carries the delivery but holds no authority over it, because every injection is checked against what the finalised block says it must have been. A sequencer that injects invalid data gets its own block rejected by its own indexer.

There is no relayer committee here, no multisig, no oracle, no extra validator set, no new token to stake. Verification is re-derivation from finalised state, so the trust model of interzone bridging is simply the trust model of the chain underneath it. Nothing crosses between the two Zones, because both of them are already reading the same blocks.

Sequencing and atomic coordination

Two related threads of work make this picture more complete.

Sequencer decentralisation is the first. Today’s design gives sequencers a job (watch, inject) but no authority (the indexer verifies everything). The team is reworking zone sequencing toward stake-gated registration with round-robin turns and posting timeouts, so no single sequencer can stall a zone, and by extension stall its cross-zone deliveries. A malicious sequencer can’t forge deliveries now; a decentralised set means one can’t withhold them either.

Second, async messaging is one half of cross-zone interaction. The other half is the Cross-Zone Atomic Coordination Protocol, a four-phase off-chain protocol (intent proposal, verification, signature exchange, submission) for the synchronous case where two zones need to commit a transaction atomically. Both sequencers hold a complete signed transaction after the signature exchange, which removes the single point of failure of classical two-phase commit. That work is still at the specification stage, with a security analysis covering abort scenarios at each phase.

Either way, the principle is the same one the rest of the Logos stack is built on. Every link in the chain gets verified on its own terms rather than inherited on trust from the link before it, which is why one compromised component draining everything is not a failure mode this architecture has.

Scope and limitations

This is LEZ-to-LEZ only. Both Zones running identical code is the premise that makes byte-for-byte re-derivation possible at all. Bridging to arbitrary external chains is a different problem and this work makes no claim on it.

Cross-Zone messaging is opt-in and off by default. A Zone with no cross-Zone configuration behaves exactly as it did before.

This is also the first part of a larger design. Follow-up work will include generalised message envelopes, an emitter-agnostic watcher, refund handling, and a broader trust and discovery model beyond the two demo flows.

This mechanism is purely Zone-to-Zone: moving tokens between the Logos blockchain and a single Zone is a separate system, already live, built on Mantle channel deposits and withdrawals and covered in the documentation.

Get involved

To try interzone bridging:

Run the two-Zone demo from the PR, send messages between Zones, and watch the timings in the chat app;

Read the indexer-side verifier and the integration tests covering forgery, replay and ingress guarding, then open an issue if there is a hole in the design;

Or work through the documentation for more on Zones, channels, and how Zone state is anchored to the chain.

Build the parallel. Prove it in practice. Keep it human.