Skip to main content
The Hyperlane Prover enables cross-chain intent verification using Hyperlane’s modular interoperability stack. It receives messages via IMessageRecipient and extends MessageBridgeProver for common proving functionality.

Architecture

Configuration

Key Points:
  • mailbox: Chain-specific Hyperlane mailbox address
  • portal: Portal contract that initiates proving
  • provers: Whitelist of trusted provers on source chains (bytes32 format for cross-VM compatibility)
  • minGasLimit: Set to 0 in constructor (no minimum enforced, unlike LayerZero)

Proving Flow

Sending Proofs (Destination → Source)

Called by Portal after intent fulfillment:
Data Parameter:

Receiving Proofs (Source Chain)

Hyperlane mailbox calls handle() with message containing:
  • 8 bytes: destination chain ID
  • 64 bytes per intent: [intentHash (32 bytes)][claimant (32 bytes)]
Only whitelisted senders accepted via isWhitelisted(sender).

Fee Calculation

Queries Hyperlane mailbox using quoteDispatch() for accurate fee. Always call before proving to avoid reverts.

Domain IDs

Critical: Hyperlane uses custom domain IDs, not chain IDs.
The sourceChainDomainID parameter must be Hyperlane’s domain ID. Consult Hyperlane Documentation for mappings. Example:
  • Ethereum: Chain ID 1 → Domain ID 1
  • Arbitrum: Chain ID 42161 → Domain ID 42161
  • Optimism: Chain ID 10 → Domain ID 10
Note: Many Hyperlane domains match chain IDs, but not all (e.g., testnets).

Metadata and Hooks

Default Configuration

Uses mailbox’s default hook:

Custom Hook

Specify custom post-dispatch hook for advanced configurations:
Hook Use Cases:
  • Custom gas payment strategies
  • Message aggregation
  • Alternative security models

Metadata

Pass custom metadata for hook configuration:
Metadata format depends on the hook being used. See Hyperlane documentation for hook-specific encoding.

Security

Whitelisting

Only provers in the whitelist can send messages:

Access Control

  • Only Hyperlane mailbox can call handle()
  • Only Portal can call prove()
  • Zero domain ID rejected: if (origin == 0) revert ZeroDomainID()

Validation

Sender validation in handle():

Integration Example

Advantages

  • Lower Costs: Generally cheaper than LayerZero
  • Modular Security: Flexible hook system for custom security models
  • Simpler Configuration: No delegate setup, domain IDs often match chain IDs
  • Transparent Security: Open-source validators and relayers

Limitations

  • Smaller Chain Coverage: ~30 chains vs LayerZero’s 50+
  • Less Mature Tooling: Fewer third-party integrations and explorers
  • Hook Complexity: Advanced features require understanding hook system
  • Bridge Dependency: Relies on Hyperlane infrastructure availability

Errors

  • MailboxCannotBeZeroAddress(): Invalid mailbox in constructor
  • ZeroDomainID(): Origin domain is zero in handle()
  • SenderCannotBeZeroAddress(): Zero sender in handle()
  • DomainIdTooLarge(uint64): Domain ID exceeds uint32.max
  • NonPortalCaller(address): Unauthorized prove() caller
  • NotWhitelisted(bytes32): Sender not in whitelist

Constant

Identifies this prover’s mechanism type.