Epic: Cross-Chain Interop via Hyperlane

[tac0turtle]

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