[EPIC] Interop

[tac0turtle]

Goal

Currently Evolve does not have a native interop story. We dont limit anyone to use other bridges but we also dont have something out of the box for users.

The goal here is to offer interop out of the box, tooling and relayers in a simple and well documented manner.

Celestia has been working with hyperlane and offers hyperlane with zkism. They allow teams to connect to any chain but also prefer people to connect to celestia in order to reduce the amount of connections needed for a team.

Description

We should offer a deployment plan and infrastructure tooling to deploy your own bridging network with an understanding of tradeoffs.

Acceptance Criteria

• Users are able to onboard and deploy their own bridge without relying on third parties
• Documentation on how to deploy and operate relayers

Related Tasks

• Developer Story 1: As a developer building on evolve, I want to deploy a bridge to celestia allowing me to bridge any asset from celestia to my chain.
• Developer Story 2: As a developer building on evolve, I want to deploy a bridge to solana allowing me to bridge any asset from solana to my chain.

Dependencies and Risks

No response

Notes and References

• Move prover program to this repo along with E2E tests #2476
• https://www.hyperlane.xyz/

[damiannolan]

Here is an intro which could be a base / starting point.

---

Hyperlane is a permissionless interoperability protocol that lets a blockchain send and receive arbitrary messages to and from other chains.

From the perspective of a chain integrating it as a bridging layer, Hyperlane is deployed as a set of core contracts that define how messages are dispatched, paid for, secured, and verified.

At the center is the canonical Mailbox, deployed once per chain with a unique domain identifier (typically equal to the chain ID, e.g. 1234). The Mailbox is the single entry point for outbound messages and the final verifier for inbound ones. When a message is dispatched, it flows through a configurable hook system: a required hook (commonly a MerkleTreeHook) records messages into an incremental Merkle tree for relaying and proof generation, while default hooks handle protocol concerns such as gas payments (via the Interchain Gas Paymaster, IGP) or flat protocol fees. On the receiving side, the Mailbox relies on an Interchain Security Module (ISM) to verify that a message is authentic; in most deployments this is most often a multisig ISM backed by a validator set, though the design supports arbitrary verification logic.

Built on top of the core messaging layer is Hyperlane applications. Warp is the flagship application offering which provides token bridging. A Warp bridge is defined by a Warp route, composed of TokenRouter contracts deployed on each participating chain. Each TokenRouter wraps a local token representation and uses the Mailbox to send standardized messages that mint, burn, lock, or release tokens across chains. Together, these TokenRouters form a logical connection between chains, while inheriting all security, fee, and verification behaviour from the underlying Mailbox, hooks, and ISMs.

---

I can expand on this and dive into more details on warp routes, hooks and ism configs.

[damiannolan]

Would be useful to have a diagram which illustrates the above. E.g. mailbox, hooks + ism with warp token router contract on top.