Secure Cross-Chain Communication via Axelar GMP Integration

When developing cross-chain solutions, bridge security is the main risk. Hacks of Cross-chain bridge and Ronin demonstrated the vulnerability of multisig schemes with 5-of-9 validators: compromising a group leads to loss of funds. We use Axelar's General Message Passing (GMP) — a decentralized network with an attack threshold of 2/3 of stake among ~75 validators. This is 10 times more secure than Multichain (5-of-9 multisig) and 20 times more decentralized than Ronin. Our experience — 5+ years in Web3 and 20+ successful integrations — guarantees reliable implementation.

Why Axelar is safer than other bridges?

Axelar uses proof-of-stake with threshold signatures (BLS). Validators have a stake in the network, and signing a transaction requires cooperation of >2/3 of the stake. This is 10 times harder to exploit than a bridge with 5-of-9 multisig. Additionally, Axelar undergoes regular security audits by leading firms like Trail of Bits. In Axelar documentation it is stated: Gas Service automatically pays gas on the destination chain, relieving the user from manual management.

Problems we solve

Cross-chain interaction faces three main challenges:

• Security: vulnerable bridges with few validators.
• Gas costs: double gas payment on both chains, often with overpayment.
• Integration complexity: need to manage keys, relayers, and statuses.

Axelar solves all three: threshold signatures improve security, Gas Service automates payment, and GMP simplifies calls. A typical mistake is incorrect gas estimation for the destination chain, causing message delivery failure. Using AxelarGMPRecoveryAPI avoids this.

What Axelar can do

Axelar's GMP enables transferring arbitrary messages between chains, enabling cross-chain calls and token transfers. Not just tokens: you can call a smart contract function in another chain with arbitrary data.

Canonical token bridging — standardized token transfers. USDC via Axelar can be Circle's native USDC (via Circle CCTP) or Axelar Wrapped USDC (axlUSDC), depending on configuration.

Squid — DEX aggregator built on top of Axelar, allowing cross-chain swaps in one transaction (swap on source chain + bridge + swap on target).

GMP integration

Source chain contract

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

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

contract SourceContract {
    IAxelarGateway public gateway;
    IAxelarGasService public gasService;
    
    constructor(address _gateway, address _gasService) {
        gateway = IAxelarGateway(_gateway);
        gasService = IAxelarGasService(_gasService);
    }
    
    function sendCrossChainMessage(
        string calldata destinationChain,      // "Polygon", "avalanche", "binance"
        string calldata destinationAddress,    // address of recipient contract
        bytes calldata payload
    ) external payable {
        // Pay gas for execution on destination chain
        gasService.payNativeGasForContractCall{value: msg.value}(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            msg.sender
        );
        
        // Send the message
        gateway.callContract(destinationChain, destinationAddress, payload);
    }
}

Destination chain contract

contract DestinationContract is AxelarExecutable {
    event MessageReceived(string sourceChain, string sourceAddress, bytes payload);
    
    constructor(address gateway) AxelarExecutable(gateway) {}
    
    // Called by Axelar when the message is delivered
    function _execute(
        string calldata sourceChain,
        string calldata sourceAddress,
        bytes calldata payload
    ) internal override {
        // Decode payload
        (address recipient, uint256 amount) = abi.decode(payload, (address, uint256));
        
        // Execute business logic
        _processMessage(sourceChain, sourceAddress, recipient, amount);
        
        emit MessageReceived(sourceChain, sourceAddress, payload);
    }
}

GMP Integration in 2-4 Weeks

The process includes the following steps:

1. Design: choose chains, contracts, interaction architecture.
2. Develop smart contracts in Solidity using Foundry/Hardhat.
3. Deploy on testnet and configure Gas Service.
4. Test cross-chain scenarios on testnet.
5. Security audit (optional).
6. Deploy on mainnet and monitor.

Estimating Gas for Cross-Chain Calls

Key detail of Axelar GMP — Gas Service. The user pays gas for both chains in one transaction (on the source chain). Axelar Gas Service converts the native token and pays the relayer on the destination chain. Estimate required gas via AxelarGMPRecoveryAPI:

import { AxelarQueryAPI, Environment, GasToken } from "@axelar-network/axelarjs-sdk";

const api = new AxelarQueryAPI({ environment: Environment.MAINNET });

const gasEstimate = await api.estimateGasFee(
  "Ethereum",           // source chain
  "Polygon",            // destination chain
  GasToken.ETH,
  300_000,              // gas limit on destination
  1.1                   // 10% buffer
);

// gasEstimate — amount in wei to pass to payNativeGasForContractCall

The average gas cost per call is around $10, but for projects processing 1000 calls per day, savings exceed $3,000 per month compared to manual relaying. Contact us for a custom assessment.

Token Transfer with GMP

For token transfer + function call on destination chain — use callContractWithToken:

function sendTokenAndCall(
    string calldata destinationChain,
    string calldata destinationAddress,
    bytes calldata payload,
    string calldata symbol,  // "USDC", "WETH"
    uint256 amount
) external payable {
    IERC20(gateway.tokenAddresses(symbol)).transferFrom(msg.sender, address(this), amount);
    IERC20(gateway.tokenAddresses(symbol)).approve(address(gateway), amount);
    
    gasService.payNativeGasForContractCallWithToken{value: msg.value}(
        address(this), destinationChain, destinationAddress, payload, symbol, amount, msg.sender
    );
    
    gateway.callContractWithToken(destinationChain, destinationAddress, payload, symbol, amount);
}

Comparison: Axelar vs other bridges

Squid integration for cross-chain swaps

import { Squid } from "@0xsquid/sdk";

const squid = new Squid({ baseUrl: "https://apiplus.squidrouter.com" });
await squid.init();

const { route } = await squid.getRoute({
  fromAddress: userAddress,
  fromChain: "1",                // Ethereum
  fromToken: "0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE", // ETH
  fromAmount: "1000000000000000000", // 1 ETH
  toChain: "137",                // Polygon
  toToken: "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174", // USDC
  toAddress: recipientAddress,
  slippage: 1.0,                 // 1%
  enableBoost: true,
});

// Execute the swap
const tx = await signer.sendTransaction(route.transactionRequest);

Deliverables

• Analytical documentation: chain interaction diagram, contract selection.
• Development and deployment of Smart Contracts in Solidity (using Foundry/Hardhat).
• Gas Service configuration and gas estimation.
• Squid integration for cross-chain swaps (optional).
• Testing on testnet and mainnet.
• Integration documentation and post-launch support.
• Access to Axelar dashboard and monitoring tools.
• Training session for your development team.

We will assess your project end-to-end. With 5+ years of Web3 experience and over 20 successful cross-chain integrations, we help you implement cross-chain functionality safely and on time.

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.