Engineering

AERE goes cross-chain, Hyperlane-compatible messenger live

By AERE Network May 31, 2026 6 min read

On May 31, 2026 AERE Network deployed a Hyperlane-Mailbox-compatible cross-chain messaging layer on chain 2800. Two contracts, one purpose: stop being a closed island. Any application on AERE can now dispatch arbitrary messages to any registered chain, and conversely, accept inbound messages verified by ECDSA-multisig signatures from an Interchain Security Module.

What this changes: the legacy AereBridge contract was a federated lock-and-release bridge with one Foundation signer, useful for the very first months of mainnet, never the long-term answer. AereMessenger replaces that with a Hyperlane-compatible message bus that can scale to 200+ chains with the same security configuration any modern L2 uses.

The two contracts

Contract	Address	What it does
AereMessenger	0xe54c2329f0786CFE3420c566B646148D25477325	Cross-chain message bus. Outbound: `dispatch(destDomain, recipient, body)` emits a Hyperlane-compatible `Dispatch` event with a unique message ID. Inbound: `process(signatures, origin, sender, recipient, body, nonce)` verifies ECDSA-multisig signatures from a configured validator set, prevents replay, and calls `IMessageRecipient.handle()` on the recipient contract.
AereIGP (Interchain Gas Paymaster)	0x61B48615F490A23945988c92835eF35fdD86E837	Receives AERE fees from outbound messages. Foundation/relayer calls `claim()` to sweep accumulated fees, which fund the gas paid on destination chains when delivering AERE-originated messages. Per-destination gas overhead and price quote are configurable.

How it composes

The contracts ship with no chain-specific assumptions baked in. Any of these flows is supported the moment counterparty contracts exist:

Cross-chain token transfers via AereWarpRoute instances (Hyperlane Warp Route pattern). Each asset gets one deployment per chain: collateral mode on the source chain, synthetic mode on AERE.
Cross-chain governance, vote on Ethereum, execute on AERE, via a relayed message.
Cross-chain oracle data, push BTC/USD from a Pyth deployment on another chain to AereOracle on AERE.
Cross-chain identity attestations, KYC issued by a BaaS partner's deployment on one chain, surfaced as an AereIdentity claim on AERE.

Security model

AereMessenger uses an ECDSA-multisig Interchain Security Module (ISM): inbound messages must carry signatures from at least threshold distinct validators in the configured validator set. Validators sign the message ID using the Ethereum-Signed-Message prefix, the same scheme Hyperlane uses, which means when AERE is added to the public Hyperlane registry, the same contracts will accept signatures from the global Hyperlane validator network without any redeploy or migration.

Phase 1 (current): Foundation operates the bootstrap validator set during the initial ramp. Threshold is 1 of 1 during the bootstrap window. This is no worse than the legacy AereBridge's 1-of-1 federation, while removing the single-point-of-failure architecture going forward.

Phase 2 (when Hyperlane registry accepts AERE): swap to the public Hyperlane validator set via addValidator() / setThreshold(N). Recommended threshold for production: 3-of-5 or higher. Each app can also deploy its own ISM if it wants stronger guarantees, for example a high-value consumer app's bridge requiring 5-of-7 with named operators.

What's still pending for full cross-chain operation

The on-chain layer is done. To make actual cross-chain transfers live in users' wallets, three follow-ups remain:

Validator + relayer Docker containers running on aere-infra (or partner infrastructure). Both are small Rust services, the validator signs outbound messages, the relayer fetches signatures and delivers messages between chains.
Open a PR to hyperlane-xyz/hyperlane-registry registering AERE chain 2800 with the Hyperlane Mailbox + IGP addresses. Once merged, every Hyperlane app on the planet auto-discovers AERE. Typical merge: 1-3 business days.
Deploy AereWarpRoute per asset, USDC, USDT, WETH, cbBTC. Each is a small contract clone on AERE plus a counterparty deployment on the source chain (Ethereum, Polygon, Arbitrum, BSC). These ship as Foundation can prioritise demand.

What this combines with

Pectra (EIP-2537 BLS precompiles), Fusaka (RIP-7951 secp256r1), the paymaster stack, and now AereMessenger together give AERE the full modern interop stack:

EIP-2537 enables cheap on-chain BLS signature verification, the cryptographic primitive Hyperlane uses for aggregated signatures on its higher-performance ISMs.
RIP-7951 enables passkey signature verification, consumer-app users can sign cross-chain transfers with Face ID via a smart wallet.
Paymaster stack covers gas, a consumer-app user paying Ethereum-side gas via their AERE-side paymaster is now a clean architectural pattern.
AereMessenger is the bus on which all of this flows.

What's next

The bridge layer being on-chain unblocks two follow-up workstreams: the Hyperlane registry PR (1-3 business days BD), and the Across Protocol integration (Tier 1.5, intent-based one-click cross-chain deposits). Across already supports Hyperlane-compatible chains, so adding it on top of AereMessenger is incremental work, not a separate bridge architecture.

Today AERE is a Layer 1 with Pectra + Fusaka parity, a working paymaster stack, and a Hyperlane-compatible message bus. The closed-island era is over.

← Back to all posts