Hyperlane

Hyperlane is the first permissionless interoperability layer. Unlike bridge protocols that require governance votes or committee approvals to add new chains, anyone can deploy Hyperlane to any blockchain — EVM, Cosmos, Sealevel (Solana), or Move — without permission. Messages are secured by configurable Interchain Security Modules (ISMs), giving developers sovereign control over their cross-chain security model rather than trusting a single validator set.

What You Probably Got Wrong

AI agents confuse Hyperlane with traditional bridges and get ISM, Warp Route, and messaging patterns wrong. These are the critical corrections.

• Hyperlane is permissionless — you CAN deploy to chains not officially supported. Unlike LayerZero or Wormhole, Hyperlane does not require a governance vote to expand to new chains. You deploy the Mailbox, ISM, and ValidatorAnnounce contracts yourself, run your own validators, and your chain is live. This is the core differentiator.
• ISMs (Interchain Security Modules) are composable — you are not locked into one security model. You can combine MultisigISM, RoutingISM, and AggregationISM to build custom security stacks. A message can require 3-of-5 validators AND an optimistic fraud proof AND a ZK proof. Security is modular, not monolithic.
• Warp Routes are NOT the same as bridges. Warp Routes are token-specific contract pairs deployed on origin and destination chains. A Warp Route for USDC on Ethereum<->Arbitrum is a separate deployment from USDC on Ethereum<->Optimism. Each route has its own collateral/synthetic relationship and ISM configuration.
• dispatch() returns a message ID, NOT a delivery confirmation. The bytes32 returned by dispatch() is a unique message identifier. It does NOT mean the message was delivered. Delivery happens asynchronously when a relayer submits the message to the destination chain's Mailbox, which then calls handle() on the recipient.
• Default ISM may differ per chain — always check what ISM your messages route through. Each Mailbox has a defaultIsm() that applies when the recipient contract does not specify its own ISM via interchainSecurityModule(). The default ISM is set by the Mailbox owner and varies across deployments.
• handle() function signature is strict: handle(uint32 _origin, bytes32 _sender, bytes _body). The _sender is bytes32, not address. For EVM origins, the sender address is left-padded with 12 zero bytes to fill 32 bytes. If you cast incorrectly, sender validation will fail silently.
• Sender addresses are bytes32 padded, not address type. When dispatching from EVM, msg.sender is converted to bytes32 via left-padding. When receiving, you must convert back: address(uint160(uint256(_sender))). Getting this wrong means your access control checks will always fail.
• Message delivery is NOT guaranteed — relayers must be running for the destination chain. Hyperlane's default relayer infrastructure covers major chains, but if you deploy to a new chain, YOU must run a relayer. No relayer = messages sit in the origin Mailbox permanently.
• Interchain gas payment is separate from dispatch. You must pay for destination chain gas via the InterchainGasPaymaster hook or a post-dispatch hook. If you skip this, the default relayer has no incentive to deliver your message. Use quoteDispatch() to estimate the fee.
• Hyperlane V3 is the current version. V3 introduced hooks (post-dispatch hooks for gas payment, custom logic), replaced the old InterchainGasPaymaster.payForGas() pattern with hook-based gas payment, and uses mailbox.dispatch() with metadata and hook parameters.