# 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

None.

## Copyright

Released to the public domain (CC0). No rights reserved.