Cross-Chain Messaging Development: LayerZero, Wormhole, Axelar

Cross-chain interaction is the bottleneck of any multi-chain architecture. We encounter daily cases where blockchain isolation hinders a product: tokens locked in one network, users unable to use DeFi on another. History remembers costly mistakes — Wormhole, Ronin, Nomad bridge hacks totaling billions of dollars. Let's explore how to build cross-chain messaging correctly using three top protocols: LayerZero, Wormhole, and Axelar. Cross-chain messaging is not just data transfer; it's an architecture of trust between isolated environments.

Why is cross-chain messaging hard?

The problem isn't sending data — technically that's trivial. The difficulty lies in trust: how to ensure that a message on the destination chain is valid and not forged? Each protocol solves this differently. LayerZero uses configurable DVNs, Wormhole uses a Guardian network of 19 nodes, Axelar uses Cosmos validators. The choice determines not only speed (from 15 seconds to 5 minutes) but also security.

LayerZero: Omnichain messaging

LayerZero v2 is the most popular protocol for EVM-to-EVM and EVM-to-non-EVM, supporting over 50 networks. The architecture separates verification and execution: DVNs (Decentralized Verifier Networks) confirm the message, Executors execute it on the destination chain. This allows configuring a security threshold: e.g., require 2 out of 3 (LayerZero Labs DVN + Google Cloud DVN + Polyhedra DVN).

How the protocol works

A message in LayerZero goes through the following path:

Source Chain: OApp.send() → EndpointV2.send() → emit PacketSent event
                                                          ↓
                                               DVNs monitor the event
                                               DVNs verify on destination
                                                          ↓
Destination Chain: EndpointV2 receives verifications → Executor calls lzReceive()

Writing an OApp (Omnichain Application)

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

import { OApp, Origin, MessagingFee } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oapp/OApp.sol";
import { OptionsBuilder } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oapp/libs/OptionsBuilder.sol";

contract CrossChainMessenger is OApp {
    using OptionsBuilder for bytes;

    event MessageReceived(uint32 srcEid, bytes32 sender, string message);

    constructor(address _endpoint, address _owner)
        OApp(_endpoint, _owner) {}

    function sendMessage(
        uint32 dstEid,
        string calldata message,
        bytes calldata options
    ) external payable {
        bytes memory payload = abi.encode(message);
        bytes memory lzOptions = OptionsBuilder.newOptions()
            .addExecutorLzReceiveOption(200_000, 0);
        MessagingFee memory fee = _quote(dstEid, payload, lzOptions, false);
        require(msg.value >= fee.nativeFee, "Insufficient fee");
        _lzSend(dstEid, payload, lzOptions, MessagingFee(msg.value, 0), payable(msg.sender));
    }

    function _lzReceive(
        Origin calldata origin,
        bytes32 guid,
        bytes calldata payload,
        address executor,
        bytes calldata extraData
    ) internal override {
        string memory message = abi.decode(payload, (string));
        emit MessageReceived(origin.srcEid, origin.sender, message);
    }

    function quoteSend(
        uint32 dstEid,
        string calldata message
    ) external view returns (uint256 nativeFee) {
        bytes memory payload = abi.encode(message);
        bytes memory options = OptionsBuilder.newOptions()
            .addExecutorLzReceiveOption(200_000, 0);
        MessagingFee memory fee = _quote(dstEid, payload, options, false);
        return fee.nativeFee;
    }
}

What is OFT and why is it needed?

The OFT standard allows a token to exist on multiple networks without wrapped versions: tokens are burned on the source chain and minted on the destination chain. The total supply remains constant. No liquidity pools, no lock-and-mint. This reduces impermanent loss risks and decreases the number of steps for the user.

import { OFT } from "@layerzerolabs/lz-evm-oapp-v2/contracts/oft/OFT.sol";

contract MyOFTToken is OFT {
    constructor(
        string memory name,
        string memory symbol,
        address lzEndpoint,
        address owner
    ) OFT(name, symbol, lzEndpoint, owner) {}
}

Wormhole: Universal messaging

Wormhole v2 supports 30+ networks: Ethereum, Solana, Cosmos, Aptos, Sui. Its architecture is a Guardian network of 19 nodes (PoA) that publish VAAs (Verifiable Action Approvals) — signed confirmations of events. Average gas cost for a VAA on Ethereum is $0.5–$2, and latency is 15–60 seconds.

Core VAA mechanics

import {
  getSignedVAAWithRetry,
  parseSequenceFromLogEth,
  CHAIN_ID_ETH,
} from "@certusone/wormhole-sdk";
import { ethers } from "ethers";

const coreBridge = new ethers.Contract(WORMHOLE_ETH_BRIDGE, BRIDGE_ABI, signer);
const tx = await coreBridge.publishMessage(0, payload, 1);
const receipt = await tx.wait();
const sequence = parseSequenceFromLogEth(receipt, WORMHOLE_ETH_BRIDGE);
const { vaaBytes } = await getSignedVAAWithRetry(
  ["https://wormhole-v2-mainnet-api.certus.one"],
  CHAIN_ID_ETH,
  emitterAddress,
  sequence,
  { retryTimeout: 1000, retryAttempts: 60 }
);
// vaaBytes contains the signed VAA for redemption on the destination chain

Wormhole vs LayerZero

If you need EVM-to-EVM — choose LayerZero v2. If your project includes Solana, Aptos, or Cosmos — look at Wormhole.

Axelar: General Message Passing

Axelar is a Cosmos-based blockchain acting as a routing layer. GMP (General Message Passing) allows arbitrary smart contract calls. It is strong for Cosmos↔EVM bridging via IBC.

import { AxelarExecutable } from "@axelar-network/axelar-gmp-sdk-solidity/contracts/executable/AxelarExecutable.sol";
import { IAxelarGasService } from "@axelar-network/axelar-gmp-sdk-solidity/contracts/interfaces/IAxelarGasService.sol";

contract CrossChainNFTBridge is AxelarExecutable {
    IAxelarGasService immutable gasService;

    constructor(address gateway, address _gasService)
        AxelarExecutable(gateway) {
        gasService = IAxelarGasService(_gasService);
    }

    function bridgeNFT(
        string calldata destChain,
        string calldata destContract,
        uint256 tokenId
    ) external payable {
        bytes memory payload = abi.encode(msg.sender, tokenId);
        gasService.payNativeGasForContractCall{value: msg.value}(
            address(this), destChain, destContract, payload, msg.sender
        );
        gateway.callContract(destChain, destContract, payload);
        // _burnNFT logic
    }

    function _execute(
        string calldata sourceChain,
        string calldata sourceAddress,
        bytes calldata payload
    ) internal override {
        (address recipient, uint256 tokenId) = abi.decode(payload, (address, uint256));
        // _mintNFT logic
    }
}

Protocol security comparison

What is included in cross-chain solution development

• Analytics: protocol selection, architecture design, gas cost estimation.
• Development: smart contracts (Solidity/Rust), off-chain relay services, frontend integration.
• Testing: unit tests, integration tests on testnet, fuzzing with Echidna.
• Audit: internal code review, external auditors (Zellic, OtterSec).
• Deployment: mainnet setup, monitoring configuration (Tenderly, Etherscan API).
• Documentation: API reference, deploy guide, troubleshooting.

How to ensure cross-chain transfer security?

Rate limiting — cap the amount of funds: if the protocol is compromised, the damage is limited. Pause mechanism with multisig (no timelock for emergencies). Trusted path validation — check that the message came from your contract.

How to choose a protocol for cross-chain messaging?

LayerZero — if you are building an omnichain token (OFT), omnichain NFT, or EVM-to-EVM data messaging with flexible security.

Wormhole — if you need Solana, Aptos, or Sui, or the widest network coverage.

Axelar — if your architecture includes Cosmos chains, or you need high-level GMP with network abstraction.

We have integrated cross-chain components in 15+ projects — from NFT bridges to DeFi aggregators. Get a consultation on cross-chain solution architecture — we will analyze your requirements and suggest the optimal protocol. Order the development of a secure bridge for your project.

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.

What Does Cross-Chain Bridge Development Include?

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

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.