Epic: Cross-Chain Interop via Hyperlane

No source files or entry points are named. Start by breaking down the Scope sections, then review the Hyperlane documentation and message-format references before defining the Evolve account mapping. Done means the listed modules, warp routes, infrastructure compatibility, demos, tests, and documentation support bidirectional transfers with an Ethereum testnet.

Goal

Enable Evolve chains to send and receive tokens to/from Celestia and Ethereum-compatible chains using Hyperlane as the cross-chain messaging layer.

Context

Evolve needs a first-class interop story. Hyperlane is a good fit because it's permissionless, modular (pluggable security via ISMs), and already deployed across Ethereum L1/L2s and Celestia. The deliverable is a Hyperlane extension for Evolve — implemented as native Evolve modules — with demo contracts that prove end-to-end token transfers work.

Scope

1. Hyperlane Core Modules

• Mailbox — Core dispatch/process account implementing Hyperlane's mailbox interface. Handles message encoding, nonce tracking, and recipient dispatch.
• Interchain Security Module (ISM) — Pluggable message verification. Start with MultisigISM (validator threshold signatures), extend to aggregation/routing ISMs later.
• Merkle Tree Hook — Post-dispatch hook that inserts message IDs into an incremental merkle tree for validator signing.
• Interchain Gas Paymaster (IGP) — Optional gas payment module for relayer incentivization.

2. Warp Route (Token Bridging)

• Native Warp Route — Lock/unlock or mint/burn pattern for Evolve's native token.
• Synthetic Warp Route — Mint/burn for bridged representations of remote tokens (e.g., wrapped ETH on Evolve).
• Collateral Warp Route — Lock/unlock for tokens already existing on Evolve that need to be bridged out.
• Token Router — Routing logic that maps remote domains to the correct warp route variant.

3. Relayer & Validator Infrastructure

• Validator agent support — Ensure Evolve exposes what Hyperlane validators need (merkle proofs, message metadata via RPC/gRPC).
• Relayer compatibility — Ensure Hyperlane relayers can index Evolve blocks, fetch proofs, and submit messages.
• Document required RPC extensions (if any) for Hyperlane agent compatibility.

4. Demo Contracts & E2E Tests

• Demo: bridge ERC-20 from Ethereum → Evolve (synthetic mint).
• Demo: bridge native Evolve token → Ethereum (lock + mint).
• Demo: Celestia ↔ Evolve token transfer (if Celestia Hyperlane deployment is available).
• Simulation tests covering message dispatch, relay, and processing.
• Property tests for mailbox invariants (nonce monotonicity, merkle consistency).

5. Documentation

• Architecture doc: how Hyperlane maps onto Evolve's account model.
• Integration guide: deploying warp routes for custom tokens.
• Operator guide: running validators and relayers for an Evolve chain.

Design Considerations

• Account model mapping: Hyperlane contracts become Evolve accounts. The Mailbox is a singleton account; ISMs and Warp Routes are separate accounts with their own storage.
• Domain ID: Evolve needs a registered Hyperlane domain ID (or use a test ID during development).
• Determinism: All Hyperlane logic must comply with Evolve's determinism rules (no HashMap, no system time).
• Message encoding: Must be byte-compatible with Hyperlane's existing message format so that existing relayers/validators work without modification.

Success Criteria

A user can deploy an Evolve chain, configure a Warp Route, and transfer tokens bidirectionally with an Ethereum testnet (Sepolia) using standard Hyperlane relayer infrastructure. Celestia support is a stretch goal dependent on their Hyperlane deployment status.

References

• Hyperlane Docs
• Hyperlane Message Format
• Warp Route Docs