AIP-11: Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC

Preamble

Field	Value
AIP	11
Title	Interoperability: Hyperlane-Compatible Messaging plus zk Light Clients, not IBC
Author	Aere Network Foundation
Type	Informational
Category	(none)
Status	Final
Created	2026-07-19
Requires	None
Supersedes	None
Superseded-By	None
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP records the decision to build cross-chain interoperability as an EVM-native, Hyperlane-compatible messaging layer plus zero-knowledge light clients, rather than adopting IBC natively. It backfills a decision already made and partly deployed.

Motivation

Aere's value proposition is that it is an ordinary EVM chain. Cross-chain interop must serve permissionless, EVM-familiar builders while also offering trust-minimized verification of a counterparty's finality, and those two goals pull in different directions.

Specification

An EVM-native, Hyperlane-compatible messaging layer: a Mailbox-compatible AereMessenger and an interchain gas paymaster AereIGP.
An ERC-7683 intent layer and an Across-v3-compatible spoke pool.
A zero-knowledge interop path: on-chain zk light clients verifying a counterparty's consensus finality from inside a contract (inbound Ethereum sync-committee finality, outbound Aere QBFT finality) via SP1 Groth16 proofs.

Rationale

IBC's design philosophy, verifying the counterparty's consensus rather than trusting a bridge committee, is the right one, and Aere adopts the philosophy directly. Aere splits the problem: for permissionless, developer-familiar interop it uses the Hyperlane-compatible interfaces the EVM tooling ecosystem already speaks; for the trust-minimization that is IBC's real contribution it built the zk light clients, which capture "verify the counterparty's consensus, do not trust a relayer" without leaving the EVM world.

Alternatives rejected. IBC as a protocol: it is built around Tendermint-style light clients and a non-EVM connection, channel, and packet model. Adopting it natively would import a substantial non-EVM stack and its tooling into a chain whose entire premise is that it is an ordinary EVM.

Backwards Compatibility

None.

Security Considerations

The Hyperlane-compatible endpoints are interface-faithful and deployed, but a live decentralized relayer and interchain-security-module network is not yet stood up: the current bridge path runs through a single Foundation signer with a relayer pending. Until that changes, the messaging layer's trust assumption is the Foundation, not a validator set.

The zk light clients are trust-minimized, not trustless, and not quantum-safe: their committed seals are classical secp256k1 and the proof wrap is Groth16 over BN254, which is Shor-breakable. A post-quantum-sound replacement is recorded in AIP-16 and is not live.

Reference Implementation and On-Chain Deployment

Deployed messaging and intent interfaces are listed in sdk-js/src/addresses.ts. The zk light-client and verifier-gateway work is under aere-contracts and the zk work trees.

Errata