Epic: Cross-Chain Interop via Hyperlane

## Goal

Enable Evolve chains to send and receive tokens to/from Celestia and Ethereum-compatible chains using [Hyperlane](https://www.hyperlane.xyz/) 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](https://docs.hyperlane.xyz/)
- [Hyperlane Message Format](https://docs.hyperlane.xyz/docs/reference/messaging/send)
- [Warp Route Docs](https://docs.hyperlane.xyz/docs/reference/applications/warp-routes)