Hyperlane Integration: Custom ISMs and Cross-Chain Bridges

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 1 of 1All 1305 services
Hyperlane Integration: Custom ISMs and Cross-Chain Bridges
Medium
~3-5 days
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1349
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1247
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    949
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1183
  • image_logo-advance_0.webp
    B2B Advance company logo design
    642
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    921

Imagine launching a new L2 on OP Stack and needing cross-chain interaction with Ethereum and other networks. LayerZero might not support your chain yet; Axelar requires lengthy onboarding. Hyperlane is the only protocol that can be deployed on a new chain permissionlessly in a couple of days. Within 2–3 weeks, your token starts moving between Ethereum and your L2. Licensing cost savings reach 40%, as confirmed by the official Hyperlane documentation.

We have already integrated Hyperlane for three projects: two L2s on OP Stack and one on Arbitrum Orbit. Each required a custom security model—exactly where Hyperlane excels. Our experience shows that Hyperlane reduces time-to-market by 5x compared to LayerZero, with licensing savings up to 40%. For a typical client, that translates to $20,000 saved annually in licensing fees.

Architecture: Mailbox, ISM, and Relayers

Hyperlane consists of three key components: Mailbox—a smart contract on each chain for sending and receiving messages; ISM—customizable message verification; Relayers—off-chain agents that forward messages. The key differentiator: anyone can deploy Hyperlane on any chain without permission. This is especially valuable for new L2/L3, appchains, and custom environments. Gas for Hyperlane messages is paid in each chain's native currency, and we help optimize these costs by selecting appropriate relayer configurations.

Why Hyperlane Wins Over Axelar and LayerZero?

Compare Hyperlane with competitors:

Parameter Hyperlane LayerZero Axelar
Permissionless deployment Yes No No
Security customization Any ISM type UltraLight Node only Generic V2
Support for new chains Days Months Months
Gas optimization Medium High Medium

Hyperlane wins on speed to new chains. Each integration takes 2–3 weeks instead of 2–3 months for LayerZero. Moreover, permissionless architecture bypasses lengthy onboarding and bureaucracy.

Custom ISM Options and Selection Criteria

Hyperlane's uniqueness: each recipient contract defines its own ISM. You decide how to verify incoming messages. Main ISM options:

  • Multisig ISM — M-of-N signatures from validators (default)
  • Aggregation ISM — combination of multiple ISMs (AND/OR logic)
  • Routing ISM — different ISMs for different source chains
  • Optimistic ISM — optimistic verification with fraud proof period
  • ZK ISM — verification via zero-knowledge proofs (in development)

ISM selection depends on required security level and speed. Multisig suits fast verification; aggregation offers maximum protection. We help determine the optimal combination.

Hyperlane Integration Timeline

Basic integration (Mailbox + ISM) takes 2–3 weeks. Adding Warp Routes for tokens extends to 4–5 weeks. This is significantly faster than competitors, where the process can take 2–3 months. Cost is calculated individually after analyzing your project. We provide an estimate within 1 business day.

Example ISM Configuration: Multisig

Steps to configure ISM:

  1. Determine the ISM type based on the security model: multisig for fast verification, aggregation for enhanced protection.
  2. Write an ISM contract implementing IInterchainSecurityModule. Example for multisig:
import {IInterchainSecurityModule} from "@hyperlane-xyz/core/contracts/interfaces/IInterchainSecurityModule.sol";
import {IMultisigIsm} from "@hyperlane-xyz/core/contracts/interfaces/isms/IMultisigIsm.sol";

contract MyCustomISM is IInterchainSecurityModule {
    address[] public validators;
    uint8 public threshold;
    
    function moduleType() external pure override returns (uint8) {
        return uint8(Types.LEGACY_MULTISIG);
    }
    
    function verify(
        bytes calldata metadata,
        bytes calldata message
    ) external override returns (bool) {
        // Determine the minimum number of validator signatures
        return _verifyMultisig(metadata, message);
    }
}
  1. Deploy the ISM contract on the target chain and register the Mailbox.
  2. Test sending messages using a test validator.
Example Warp Route for Tokens

Warp Route creates synthetic token bridges. Below is an example sender contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import {IMailbox} from "@hyperlane-xyz/core/contracts/interfaces/IMailbox.sol";

contract HyperlaneMessageSender {
    IMailbox public mailbox;
    
    constructor(address _mailbox) {
        mailbox = IMailbox(_mailbox);
    }
    
    function sendMessage(
        uint32 destinationDomain,
        bytes32 recipientAddress,
        bytes calldata messageBody
    ) external payable {
        uint256 fee = mailbox.quoteDispatch(destinationDomain, recipientAddress, messageBody);
        require(msg.value >= fee, "Insufficient gas payment");
        
        bytes32 messageId = mailbox.dispatch{value: fee}(
            destinationDomain,
            recipientAddress,
            messageBody
        );
        
        emit MessageSent(messageId, destinationDomain);
    }
}
import {IMessageRecipient} from "@hyperlane-xyz/core/contracts/interfaces/IMessageRecipient.sol";

contract HyperlaneMessageReceiver is IMessageRecipient {
    mapping(uint32 => bytes32) public enrolledSenders;
    
    function handle(
        uint32 origin,
        bytes32 sender,
        bytes calldata message
    ) external payable override {
        require(msg.sender == address(mailbox), "Only mailbox");
        require(enrolledSenders[origin] == sender, "Unknown sender");
        (address recipient, uint256 amount) = abi.decode(message, (address, uint256));
        _processMessage(origin, recipient, amount);
    }
}

Domain IDs

Hyperlane uses its own domain IDs:

Chain Domain ID
Ethereum 1
Polygon 137
Arbitrum 42161
Optimism 10
Base 8453
BSC 56

Deploying Hyperlane on a New Chain

The main advantage of Hyperlane is permissionless deployment. To deploy on an AppChain:

npm install -g @hyperlane-xyz/cli
hyperlane deploy core --chains myappchain --key 0xYourPrivateKey
hyperlane deploy ism multisig --chains myappchain --validators 0xValidator1,0xValidator2,0xValidator3 --threshold 2

What's Included in the Work and Timelines

When ordering a turnkey Hyperlane integration, we provide:

  • Architecture audit and optimal ISM selection
  • Writing smart contracts for sending/receiving messages and Warp Routes
  • Deployment on target chains (including testnet)
  • End-to-end testing and security checks using Slither, Mythril, Echidna
  • Full integration documentation and operational instructions
  • Training for your team (2–3 hour workshop)

Timelines: from 2 to 5 weeks depending on complexity. Cost is calculated individually after analyzing your project. We provide an estimate within 1 business day.

Our engineers have over 10 successful integrations with cross-chain protocols, 5+ years on the market. We guarantee stable operation and timely delivery. If you want to accelerate time-to-market and save budget, contact us for a consultation. Our engineers will assess your project within 1 business day and propose the optimal architecture. Order a turnkey Hyperlane integration and receive full documentation, team training, and ready smart contracts.

Learn more about the protocol in the Hyperlane Monorepo.

10+ successful integrations | 5+ years on market | 40% cost savings

Cross-Chain Bridge Development: Architecture, Risks, and Implementation

We develop cross-chain bridges and cross-chain solutions end-to-end. We know how to avoid disasters. A few years ago, the Binance BNB Chain bridge lost $570M — the attacker forged a Merkle proof in BSC's native bridge. That same year, Wormhole lost $320M: guardian signature verification was bypassed through a bug in Solana's secp256k1 program. Ronin Bridge — $625M. These are not coincidences. Bridges are the most attacked infrastructure in Web3 because they aggregate liquidity and have complex cross-chain verification logic.

Why Do Bridges Break? Three Architectural Classes of Vulnerabilities

Finality and Reorg Issues. Ethereum has probabilistic finality before The Merge and economic finality after (2 epochs, ~12 minutes). Bitcoin — ~6 blocks (~60 minutes). Solana — ~400ms. If a bridge mints wrapped tokens on the destination chain immediately after 1-2 blocks on the source — a reorg of 3+ blocks allows the attacker to obtain tokens on the destination while the source transaction is reverted. Correct protection: wait for finality confirmation specific to each chain. For Ethereum — 64+ blocks (2 epochs). Not one block.

Signature Verification. Most bridges use a multisig committee or threshold signature: N out of M validators must sign the event from the source chain. Wormhole used 13 out of 19 guardians. The attack was not on the keys themselves — the attacker found a vulnerability in the signature verification code on Solana, where an outdated sysvar account was accepted as valid without verification. On-chain signature verification is harder than it seems.

Lock-and-Mint vs Burn-and-Mint. In the lock-and-mint model, original tokens are locked in a contract on the source chain, and wrapped tokens are minted on the destination. The source contract is a honeypot: all locked TVL is there. One bug in the unlock logic — and all funds are available to the attacker without needing to do anything on the destination chain. Native burn-and-mint (like Circle CCTP for USDC) is safer: no locked pool.

How to Choose a Messaging Layer for Your Project?

LayerZero — a protocol for arbitrary message passing between chains. Not a bridge itself, but infrastructure for building bridges and omnichain applications.

Architecture: Endpoint contract on each chain, Executor (delivers messages to the destination chain), DVN (Decentralized Verifier Network — verifies the transaction fact on the source chain).

Source chain:
  OApp.send() → Endpoint.send() → [emits packet event]

Destination chain:
  DVN verifies packet hash → Executor calls Endpoint.deliver() → OApp.lzReceive()

In v2, the developer chooses DVNs: official (LayerZero Labs, Google Cloud, Polyhedra), or custom. One can configure required DVN + optional DVN: a message is accepted only if all required DVNs confirm. This allows building bridges with different trade-offs between security and speed.

OApp (Omnichain Application) — the base contract for integration. Inherit OApp, implement _lzSend and _lzReceive. For token bridges — OFT (Omnichain Fungible Token) standard out of the box does burn-on-source / mint-on-destination.

Wormhole uses a network of 19 guardians (large companies like Jump Crypto, Everstake, etc.), each signing observed events. Threshold — 13 out of 19. VAA (Verified Action Approval) — a signed message that is accepted on the destination chain.

Main difference from LayerZero: Wormhole has native support for non-EVM chains: Solana, Aptos, Sui, Algorand, Near. For projects needing a bridge between Ethereum and Solana — Wormhole is often the only production-ready option.

After the exploit, Wormhole added Native Token Transfers (NTT) — an architecture without a locked pool, similar to CCTP. NTT + Hub-and-Spoke model: redundant liquidity is not accumulated on one chain.

Relay Architecture and Light Client Verification

Relay-based bridges (IBC in Cosmos ecosystem, Succinct's Telepathy) verify the source chain's state via a light client on the destination chain. For EVM→EVM: a contract on Ethereum stores and verifies BLS signatures of the source chain's blocks.

ZK-bridges are the next level. Succinct, Polyhedra zkBridge, Electron Labs generate a ZK-proof of the correctness of the source chain's consensus. On the destination chain, the proof is verified, not the validator signatures. Removes trust in the committee. But ZK-proof verification is gas-expensive — from 200k to 500k gas on Ethereum L1 depending on the proof system. A ZK-bridge is safer than a relay-based bridge but requires 2-3 times more gas for verification.

Characteristic LayerZero Wormhole IBC (Cosmos) ZK-bridge
EVM support All EVM + Solana, Aptos All EVM + Solana, Aptos, Sui Cosmos chains Growing
Trust model DVN (configurable) 13/19 guardians Light client ZK proof
Latency 1-5 min 1-5 min ~30 sec 5-30 min
Gas for verification ~100-150k ~150-200k ~200-300k 200-500k

What Does Cross-Chain Bridge Development Include?

We implement the project turnkey and deliver a complete set of results. Our clients receive:

Stage Result
Analysis and architecture selection Technical specification, rationale for messaging layer choice
Smart contract design Specification, flow diagrams, trust model description
Development and testing Source code, unit/integration tests, cross-chain scenario simulation
Security audit External auditor report, fixed vulnerabilities
Deployment and monitoring Mainnet contracts, alert dashboard, operations documentation
Post-launch support 3 months warranty support, operations assistance

Implementation: What to Consider Before the First Line of Code

Mandatory components for any production bridge:

Pauser. Emergency pause function, called by multisig or automatically upon anomaly detection (suspicious volume, atypical call sequence). Most hacked bridges did not have or did not use a pauser in time.

Rate limiting. Limit output volume per time interval. If an attacker drains the bridge — rate limit gives time to react. Implementation: transferVolume[currentEpoch] += amount; require(transferVolume[currentEpoch] <= epochLimit).

Finality checks. Specific to each chain. Not "wait 1 block", but use finality API or wait for required number of confirmations.

Relayer monitoring. An autonomous service that monitors the state of both bridge sides. If a message is sent but not delivered within N minutes — alert. If locked balance diverges from totalSupply of wrapped token — critical alert.

Timeline and Cost

A simple ERC-20 bridge on top of an existing messaging layer (LayerZero OFT or Wormhole NTT) — 4-8 weeks including testing and audit. A custom bridge with own verification, multi-chain support, rate limiting, monitoring — 12-24 weeks. A ZK-bridge with custom proof circuits — from 6 months.

Bridge audit takes longer than a standard DeFi protocol audit: cross-chain scenarios, finality edge cases, reorg attacks must be tested. Minimum 3-4 weeks for a production-grade solution.

Cost is calculated individually after workload assessment. We have been working since 2018 and have completed 15+ projects in blockchain infrastructure. Contact us — we will evaluate your project and propose the optimal bridge architecture.