From 6e6b51aa6fb4107ceafe2ab32fec1561e8e042b1 Mon Sep 17 00:00:00 2001 From: krystal <56278409+theekrystallee@users.noreply.github.com> Date: Tue, 24 Feb 2026 14:56:55 -0800 Subject: [PATCH 1/3] added axelar integration docs Signed-off-by: krystal <56278409+theekrystallee@users.noreply.github.com> --- docs.json | 3 +- .../interoperability-and-bridging/axelar.mdx | 252 ++++++++++++++++++ 2 files changed, 254 insertions(+), 1 deletion(-) create mode 100644 hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx diff --git a/docs.json b/docs.json index 4ceb469f..0789e28c 100644 --- a/docs.json +++ b/docs.json @@ -577,7 +577,8 @@ "pages": [ "hedera/open-source-solutions/interoperability-and-bridging", "hedera/open-source-solutions/interoperability-and-bridging/layerzero", - "hedera/open-source-solutions/interoperability-and-bridging/chainlink" + "hedera/open-source-solutions/interoperability-and-bridging/chainlink", + "hedera/open-source-solutions/interoperability-and-bridging/axelar" ] }, { diff --git a/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx b/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx new file mode 100644 index 00000000..7420b710 --- /dev/null +++ b/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx @@ -0,0 +1,252 @@ +--- +title: Axelar +description: Learn how Axelar's Interchain Token Service (ITS) and General Message Passing (GMP) integrate with Hedera to enable cross-chain token transfers and arbitrary messaging. +--- + +## What is Axelar? + +Axelar is a decentralized interoperability network that lets blockchains communicate and transfer assets with each other. It runs its own proof-of-stake chain, where a decentralized set of **57 active validators** verify cross-chain messages and reach consensus before anything is executed on the destination chain. This architecture means there is no single trusted relayer — security comes from the validator set itself. + +For developers building on Hedera, Axelar exposes two main capabilities: + +- **Interchain Token Service (ITS):** A mint/burn bridge that lets you deploy tokens across **83 connected chains**, or register an existing token so it can move freely between Hedera and any other Axelar-connected network. +- **General Message Passing (GMP):** A protocol for calling arbitrary functions on contracts deployed on other chains — enabling cross-chain governance, NFT marketplaces, gaming, and more. + +## Overview of Axelar and HTS Compatibility + +Axelar's ITS is designed to work with Hedera Token Service (HTS) tokens natively. When a new Interchain Token is deployed on Hedera, ITS creates an HTS token rather than a standard ERC-20. This means the token is a first-class citizen on Hedera — it appears in wallets, is visible on HashScan, and benefits from HTS's built-in compliance features. + +That said, HTS has architectural differences from ERC-20 that affect how ITS behaves on Hedera. The most important ones are covered in the [Developer Considerations](#developer-considerations) section below. + +## Getting Started with Axelar on Hedera + + + + + + + +## Key Components + +### Interchain Token Service (ITS) + +ITS is the primary way to bridge tokens to and from Hedera using Axelar. It supports two main flows: + +**Deploy a new Interchain Token** + +If you want to launch a new token that exists natively on multiple chains, ITS handles the full deployment. On Hedera, this creates a new HTS token. On EVM chains, it deploys a standard ERC-20. The token is fungible across all connected chains at a 1:1 ratio with no slippage, because the bridge uses mint/burn rather than liquidity pools. + +**Register an existing token** + +If your token already exists on another chain (for example, Ethereum mainnet), you can register it with ITS and deploy a corresponding representation on Hedera. ITS deploys a `TokenManager` contract on Hedera that acts as the sole minter and burner for the HTS token. + +**ITS Portal (No-Code)** + +The [ITS Portal](https://interchain.axelar.dev/) provides a web interface for both flows. The steps for bridging an existing Ethereum token to Hedera are: + +1. Connect your wallet and enter your token's address on the source chain (e.g., Ethereum mainnet). +2. Register the token with ITS on the source chain. +3. Select Hedera as the destination chain and deploy the token representation. +4. Your token is now bridgeable between Ethereum and Hedera, and automatically listed on [Squid](https://www.squidrouter.com/) for cross-chain swaps. + +**Squid Router Integration** + +All ITS bridges are automatically whitelisted on Squid, which is integrated into MetaMask, PancakeSwap, Jumper, and many other DeFi applications. This means your token gets immediate distribution without any additional integration work. + +**Flow Limits** + +ITS supports configurable daily transfer limits per token. This is a security feature that caps how much of a token can be bridged in a 24-hour window. Axelar can help configure flow limits for tokens deployed through the ITS Portal. + +--- + +### General Message Passing (GMP) + +GMP lets a smart contract on Hedera call a function on a contract deployed on any other Axelar-connected chain, and vice versa. The flow works as follows: + +1. Your contract on Hedera calls `callContract()` on the Axelar Gateway, specifying the destination chain, destination contract address, and an encoded payload. +2. You pay gas fees upfront to the Axelar Gas Service in the same transaction. Overpaid gas is refunded. +3. Axelar validators observe the event, reach consensus, and relay the approved message to the destination chain. +4. The Axelar executor calls `execute()` on your destination contract, which decodes the payload and runs your logic. + +The full round trip typically completes in under 4 minutes on testnet. + +**Contract Addresses** + +| Network | Gateway | Gas Service | +| :--- | :--- | :--- | +| **Testnet** | `0xe432150cce91c13a887f7D836923d5597adD8E31` | `0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6` | +| **Mainnet** | `0xe432150cce91c13a887f7D836923d5597adD8E31` | `0x2d5d7d31F671F86C782533cc367F14109a082712` | + +**Hedera chain name for GMP calls** + +When specifying the destination chain in a `callContract()` call, use the string `"hedera"` (lowercase). For example: + +```solidity +gateway.callContract("hedera", destinationContractAddress, payload); +``` + +**Example: Sending a message from Hedera to Avalanche** + +The following example uses the `SourceMessenger` contract from the [GMP examples repo](https://github.com/skurzyp-arianelabs/axelar-gmp-tests). It sends a string message from Hedera testnet to Avalanche Fuji. + +Deploy the sender on Hedera and the receiver on Avalanche: + +```shell +CHAIN=hedera CONTRACT_PAIR=messenger forge script script/UniversalDeploy.s.sol \ + --rpc-url https://testnet.hashio.io/api \ + --private-key $HEDERA_KEY \ + --broadcast + +CHAIN=avalanche CONTRACT_PAIR=messenger forge script script/UniversalDeploy.s.sol \ + --rpc-url https://api.avax-test.network/ext/bc/C/rpc \ + --private-key $AVAX_KEY \ + --broadcast +``` + +Send a message from Hedera to the `DestLogger` contract on Avalanche. The `--value` flag pays the Axelar gas fee: + +```shell +cast send \ + "sendMessage(string,string,string)" "avalanche" "" "hello from hedera" \ + --rpc-url https://testnet.hashio.io/api \ + --private-key $HEDERA_KEY \ + --value 1ether +``` + +Check the received message on Avalanche: + +```shell +cast call "lastMessage()" \ + --rpc-url https://api.avax-test.network/ext/bc/C/rpc +``` + +The output is ABI-encoded. Decode it with: + +```shell +cast --to-utf8 +``` + +You can trace the full cross-chain transaction on [AxelarScan](https://testnet.axelarscan.io/) using the transaction hash from the `cast send` command. + +**Example: Sending a counter value from Hedera to Avalanche** + +```shell +cast send \ + "increment(string,string,uint256)" "avalanche" "" 1 \ + --rpc-url https://testnet.hashio.io/api \ + --private-key $HEDERA_KEY \ + --value 1ether +``` + +Read the updated counter on Avalanche: + +```shell +cast call "count()" \ + --rpc-url https://api.avax-test.network/ext/bc/C/rpc +``` + + + The `--value` parameter is mandatory for all GMP calls. It pays the Axelar gas fee for the cross-chain execution. Any overpaid amount is automatically refunded. You can estimate the required fee at: `https://testnet.api.axelarscan.io/gas-payment/gas-fee/{sourceChain}/{destinationChain}`. + + +--- + +## Developer Considerations + +HTS has several architectural differences from ERC-20 that affect how Axelar ITS and GMP behave on Hedera. Review these carefully before building. + +### Token Creation Fee and WHBAR + +Creating a new HTS token requires a fee paid in HBAR. Because ITS contracts are EVM-based and cannot hold HBAR directly, the ITS implementation on Hedera uses **Wrapped HBAR (WHBAR)** — an ERC-20 compatible wrapper for HBAR — to pay this fee. When deploying a new Interchain Token on Hedera, you must ensure the deploying account has sufficient WHBAR approved for the `InterchainTokenFactory` contract. + +You can fund an address with WHBAR and approve the factory using the utility scripts in the [axelar-contract-deployments](https://github.com/axelarnetwork/axelar-contract-deployments/tree/main/hedera) repo: + +```shell +# Deposit HBAR and convert to WHBAR +node hedera/fund-whbar.js --amount 10 --env testnet -n hedera + +# Approve the InterchainTokenFactory to spend your WHBAR +node hedera/approve-factory-whbar.js --amount max --env testnet -n hedera +``` + +### No Initial Supply on Deploy + +Deploying a new Interchain Token with an initial supply is **not currently supported** on Hedera. This is because an account must be explicitly associated with an HTS token before it can receive a balance. When a new token is deployed, the deploying account is not automatically associated, so minting an initial supply would fail or result in a gas charge with no tokens received. + +This behavior may be updated in a future version of the `InterchainTokenFactory` contract. + +### Non-Deterministic HTS Token Addresses + +Unlike ERC-20 tokens, HTS tokens do not have addresses derived from the deployer's address and nonce. The address assigned to a new HTS token is non-deterministic. After deploying a new Interchain Token on Hedera, retrieve its address by calling: + +```solidity +address tokenAddress = IInterchainTokenService(its).registeredTokenAddress(tokenId); +``` + +### Token Association Requirement + +Before any account or contract can receive an HTS token, it must be **associated** with that token. This is a Hedera-specific requirement with no EVM equivalent. + +If your contract needs to receive ITS tokens (for example, as part of a GMP call that also transfers tokens), it must implement the `InterchainTokenExecutable` interface and associate itself with the token before any transfers occur. One way to do this is: + +```solidity +function associateWithToken(address tokenAddress_) external { + IHRC719(tokenAddress_).associate(); +} +``` + +The `IHRC719` interface abstracts the HTS precompile, so your contract does not need to interact with the HTS library directly. + +### Unsupported Token Key Types + +HTS tokens support several optional key types that control administrative operations. ITS does not support tokens that have the following keys set: + +- `kycKey` +- `wipeKey` +- `freezeKey` +- `pauseKey` + +An `adminKey` can be used to update existing keys, but it **cannot** add new keys if they were not defined when the token was created. + +### Maximum Supply + +The maximum supply for an HTS token is **2^63 − 1**, which is significantly smaller than the 2^256 − 1 maximum for standard ERC-20 tokens. Ensure your token's total supply does not exceed this limit. + +### HTS Tokens as ERC-20 + +HTS tokens support ERC-20 facade methods (`name`, `balanceOf`, `transfer`, `transferFrom`, `approve`, `allowance`) via [HIP-218](https://hips.hedera.com/hip/hip-218) and [HIP-376](https://hips.hedera.com/hip/hip-376). However, `mint` and `burn` are not part of the ERC-20 facade — they are handled directly by the `TokenManager` contract through the HTS precompile. HTS tokens also do not emit `Transfer` events to and from the zero address on mint and burn. + +--- + +## Additional Resources + +| Resource | Description | +| :--- | :--- | +| [Axelar Documentation](https://docs.axelar.dev/) | Full Axelar developer documentation, including GMP and ITS guides | +| [ITS Portal](https://interchain.axelar.dev/) | No-code interface for deploying and managing Interchain Tokens | +| [Squid Router](https://www.squidrouter.com/) | Cross-chain swap and bridging platform powered by Axelar ITS | +| [AxelarScan](https://axelarscan.io/) | Block explorer for tracing cross-chain transactions | +| [axelar-contract-deployments](https://github.com/axelarnetwork/axelar-contract-deployments/tree/main/hedera) | Deployment scripts and utilities for Hedera ITS contracts | +| [axelar-gmp-tests](https://github.com/skurzyp-arianelabs/axelar-gmp-tests) | GMP example contracts and Foundry scripts for Hedera | +| [Hedera ITS contracts (commonprefix fork)](https://github.com/commonprefix/interchain-token-service/tree/hedera-its) | The Hedera-specific fork of the ITS contracts with HTS support | +| [HashScan Explorer](https://hashscan.io/) | Hedera network explorer for verifying token deployments and transactions | + +## Summary + +**Axelar** connects Hedera to a cross-chain ecosystem of 83 networks through two complementary protocols. **ITS** provides a no-code, mint/burn bridge for tokens — eliminating liquidity fragmentation and giving tokens the same address across all connected EVM chains. **GMP** enables arbitrary cross-chain function calls, opening the door to complex multi-chain applications built on Hedera. + +Because Hedera's token model differs from EVM standards, working with Axelar on Hedera requires attention to HTS-specific details: token association, WHBAR for creation fees, non-deterministic addresses, and supply limits. The [Developer Considerations](#developer-considerations) section above covers each of these in detail. + +This complements the other interoperability solutions available on Hedera, including [**LayerZero**](./layerzero) and [**Chainlink CCIP**](./chainlink). From 0f7f7f49f932ec85cd5f9987725939466278effd Mon Sep 17 00:00:00 2001 From: krystal <56278409+theekrystallee@users.noreply.github.com> Date: Tue, 24 Feb 2026 15:04:12 -0800 Subject: [PATCH 2/3] added axelar integration docs Signed-off-by: krystal <56278409+theekrystallee@users.noreply.github.com> --- .../interoperability-and-bridging/axelar.mdx | 221 +++++++++--------- 1 file changed, 104 insertions(+), 117 deletions(-) diff --git a/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx b/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx index 7420b710..e8d96a5f 100644 --- a/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx +++ b/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx @@ -3,6 +3,8 @@ title: Axelar description: Learn how Axelar's Interchain Token Service (ITS) and General Message Passing (GMP) integrate with Hedera to enable cross-chain token transfers and arbitrary messaging. --- +import { Card, Cards, Info, Warning } from "mintlify"; + ## What is Axelar? Axelar is a decentralized interoperability network that lets blockchains communicate and transfer assets with each other. It runs its own proof-of-stake chain, where a decentralized set of **57 active validators** verify cross-chain messages and reach consensus before anything is executed on the destination chain. This architecture means there is no single trusted relayer — security comes from the validator set itself. @@ -26,180 +28,163 @@ That said, HTS has architectural differences from ERC-20 that affect how ITS beh title="➡ ITS PORTAL" body="No-code bridge deployment. Register an existing token or deploy a new one across chains in minutes." /> + - ## Key Components ### Interchain Token Service (ITS) -ITS is the primary way to bridge tokens to and from Hedera using Axelar. It supports two main flows: +ITS is the primary way to bridge tokens to and from Hedera using Axelar. It supports two main flows: a no-code portal for simple deployments and a programmatic workflow for developers. -**Deploy a new Interchain Token** +#### ITS Portal (No-Code) -If you want to launch a new token that exists natively on multiple chains, ITS handles the full deployment. On Hedera, this creates a new HTS token. On EVM chains, it deploys a standard ERC-20. The token is fungible across all connected chains at a 1:1 ratio with no slippage, because the bridge uses mint/burn rather than liquidity pools. +The [ITS Portal](https://interchain.axelar.dev/) provides a web interface for both deploying new tokens and registering existing ones. The steps for bridging an existing Ethereum token to Hedera are: -**Register an existing token** +1. Connect your wallet and enter your token's address on the source chain (e.g., Ethereum mainnet). +2. Register the token with ITS on the source chain. +3. Select Hedera as the destination chain and deploy the token representation. +4. Your token is now bridgeable between Ethereum and Hedera, and automatically listed on [Squid](https://www.squidrouter.com/) for cross-chain swaps. -If your token already exists on another chain (for example, Ethereum mainnet), you can register it with ITS and deploy a corresponding representation on Hedera. ITS deploys a `TokenManager` contract on Hedera that acts as the sole minter and burner for the HTS token. +#### Programmatic ITS Workflow (CLI) -**ITS Portal (No-Code)** +For developers who need more control, the `axelar-contract-deployments` repository provides CLI scripts to manage the entire ITS lifecycle. The following is a verified workflow for deploying a new HTS-backed Interchain Token from Hedera to other chains. -The [ITS Portal](https://interchain.axelar.dev/) provides a web interface for both flows. The steps for bridging an existing Ethereum token to Hedera are: +**Prerequisites:** -1. Connect your wallet and enter your token's address on the source chain (e.g., Ethereum mainnet). -2. Register the token with ITS on the source chain. -3. Select Hedera as the destination chain and deploy the token representation. -4. Your token is now bridgeable between Ethereum and Hedera, and automatically listed on [Squid](https://www.squidrouter.com/) for cross-chain swaps. +- A Hedera testnet account with HBAR. +- The `axelar-contract-deployments` repo cloned locally. -**Squid Router Integration** +**Step 1: Prepare the Hedera Account (Wrap HBAR & Approve)** -All ITS bridges are automatically whitelisted on Squid, which is integrated into MetaMask, PancakeSwap, Jumper, and many other DeFi applications. This means your token gets immediate distribution without any additional integration work. +First, wrap some HBAR into WHBAR and approve the `InterchainTokenFactory` to spend it. This is required to pay the HTS token creation fee. -**Flow Limits** +```shell +# Deposit HBAR and convert to WHBAR +# Note the plural --chainNames flag +node hedera/fund-whbar.js --chainNames hedera --amount 40 -ITS supports configurable daily transfer limits per token. This is a security feature that caps how much of a token can be bridged in a 24-hour window. Axelar can help configure flow limits for tokens deployed through the ITS Portal. +# Approve the InterchainTokenFactory to spend your WHBAR +node hedera/approve-factory-whbar.js --chainName hedera --amount max +``` ---- +**Step 2: Deploy the Interchain Token on Hedera** -### General Message Passing (GMP) +This command creates the new HTS token on Hedera. Note that `initialSupply` must be `0`. -GMP lets a smart contract on Hedera call a function on a contract deployed on any other Axelar-connected chain, and vice versa. The flow works as follows: +```shell +ts-node evm/interchainTokenFactory.js --action deployInterchainToken \ + --minter \ + --name "My Interchain Token" \ + --symbol "MIT" \ + --decimals 8 \ + --salt "any-unique-salt-123" \ + --initialSupply 0 \ + -n hedera +``` -1. Your contract on Hedera calls `callContract()` on the Axelar Gateway, specifying the destination chain, destination contract address, and an encoded payload. -2. You pay gas fees upfront to the Axelar Gas Service in the same transaction. Overpaid gas is refunded. -3. Axelar validators observe the event, reach consensus, and relay the approved message to the destination chain. -4. The Axelar executor calls `execute()` on your destination contract, which decodes the payload and runs your logic. +This will output the `tokenId` and the Hedera `tokenAddress` (e.g., `0x00...0069d5A1`). -The full round trip typically completes in under 4 minutes on testnet. +**Step 3: Associate Your Account with the New Token** -**Contract Addresses** +Before you can mint or receive the new token, your account must be associated with it. -| Network | Gateway | Gas Service | -| :--- | :--- | :--- | -| **Testnet** | `0xe432150cce91c13a887f7D836923d5597adD8E31` | `0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6` | -| **Mainnet** | `0xe432150cce91c13a887f7D836923d5597adD8E31` | `0x2d5d7d31F671F86C782533cc367F14109a082712` | +```shell +ts-node hedera/associate-token.js +``` -**Hedera chain name for GMP calls** +**Step 4: Deploy the Token to a Remote Chain** -When specifying the destination chain in a `callContract()` call, use the string `"hedera"` (lowercase). For example: +Now, deploy a canonical representation of your token to another chain, like Avalanche. -```solidity -gateway.callContract("hedera", destinationContractAddress, payload); +```shell +ts-node evm/interchainTokenFactory.js --action deployRemoteInterchainToken \ + --destinationChain Avalanche \ + --salt "any-unique-salt-123" \ + --gasValue 10000000 \ + -y -n hedera ``` -**Example: Sending a message from Hedera to Avalanche** + + **Chain Name Casing:** When using the CLI, the destination chain name must be the exact `axelarId` from the `axelar-chains-config` repository (e.g., `Avalanche`, `Polygon`). However, when calling GMP contracts directly, the chain name must be **lowercase** (e.g., `avalanche`, `polygon`). + -The following example uses the `SourceMessenger` contract from the [GMP examples repo](https://github.com/skurzyp-arianelabs/axelar-gmp-tests). It sends a string message from Hedera testnet to Avalanche Fuji. +**Step 5: Mint, Approve, and Transfer** -Deploy the sender on Hedera and the receiver on Avalanche: +Once deployed, you can mint new tokens on Hedera, approve the `TokenManager` to spend them, and perform an interchain transfer. ```shell -CHAIN=hedera CONTRACT_PAIR=messenger forge script script/UniversalDeploy.s.sol \ - --rpc-url https://testnet.hashio.io/api \ - --private-key $HEDERA_KEY \ - --broadcast - -CHAIN=avalanche CONTRACT_PAIR=messenger forge script script/UniversalDeploy.s.sol \ - --rpc-url https://api.avax-test.network/ext/bc/C/rpc \ - --private-key $AVAX_KEY \ - --broadcast -``` +# Mint new tokens to your account +ts-node evm/its.js mint-token 100000000 -y -n hedera -Send a message from Hedera to the `DestLogger` contract on Avalanche. The `--value` flag pays the Axelar gas fee: +# Approve the TokenManager to spend them +ts-node evm/its.js approve 100000000 -y -n hedera -```shell -cast send \ - "sendMessage(string,string,string)" "avalanche" "" "hello from hedera" \ - --rpc-url https://testnet.hashio.io/api \ - --private-key $HEDERA_KEY \ - --value 1ether +# Transfer tokens from Hedera to Avalanche +ts-node evm/its.js interchain-transfer Avalanche 1 --gasValue 1000000000 -y -n hedera ``` -Check the received message on Avalanche: +--- -```shell -cast call "lastMessage()" \ - --rpc-url https://api.avax-test.network/ext/bc/C/rpc -``` +### General Message Passing (GMP) -The output is ABI-encoded. Decode it with: +GMP lets a smart contract on Hedera call a function on a contract deployed on any other Axelar-connected chain, and vice versa. -```shell -cast --to-utf8 -``` +**Contract Addresses** -You can trace the full cross-chain transaction on [AxelarScan](https://testnet.axelarscan.io/) using the transaction hash from the `cast send` command. +| Network | Gateway | Gas Service | +| :--- | :--- | :--- | +| **Testnet** | `0xe432150cce91c13a887f7D836923d5597adD8E31` | `0xbE406F0189A0B4cf3A05C286473D23791Dd44Cc6` | +| **Mainnet** | `0xe432150cce91c13a887f7D836923d5597adD8E31` | `0x2d5d7d31F671F86C782533cc367F14109a082712` | -**Example: Sending a counter value from Hedera to Avalanche** +**Example: Sending a message from Hedera to Avalanche** + +The following example uses `foundry cast` to send a message from a contract on Hedera testnet to a contract on Avalanche Fuji. ```shell -cast send \ - "increment(string,string,uint256)" "avalanche" "" 1 \ +# Send a message from Hedera to the DestLogger contract on Avalanche +# Note the lowercase "avalanche" and the --value flag for gas +cast send \ + "sendMessage(string,string,string)" "avalanche" "" "hello from hedera" \ --rpc-url https://testnet.hashio.io/api \ --private-key $HEDERA_KEY \ --value 1ether ``` -Read the updated counter on Avalanche: - -```shell -cast call "count()" \ - --rpc-url https://api.avax-test.network/ext/bc/C/rpc -``` - The `--value` parameter is mandatory for all GMP calls. It pays the Axelar gas fee for the cross-chain execution. Any overpaid amount is automatically refunded. You can estimate the required fee at: `https://testnet.api.axelarscan.io/gas-payment/gas-fee/{sourceChain}/{destinationChain}`. --- -## Developer Considerations +## Developer Considerations & Known Issues HTS has several architectural differences from ERC-20 that affect how Axelar ITS and GMP behave on Hedera. Review these carefully before building. ### Token Creation Fee and WHBAR -Creating a new HTS token requires a fee paid in HBAR. Because ITS contracts are EVM-based and cannot hold HBAR directly, the ITS implementation on Hedera uses **Wrapped HBAR (WHBAR)** — an ERC-20 compatible wrapper for HBAR — to pay this fee. When deploying a new Interchain Token on Hedera, you must ensure the deploying account has sufficient WHBAR approved for the `InterchainTokenFactory` contract. - -You can fund an address with WHBAR and approve the factory using the utility scripts in the [axelar-contract-deployments](https://github.com/axelarnetwork/axelar-contract-deployments/tree/main/hedera) repo: - -```shell -# Deposit HBAR and convert to WHBAR -node hedera/fund-whbar.js --amount 10 --env testnet -n hedera - -# Approve the InterchainTokenFactory to spend your WHBAR -node hedera/approve-factory-whbar.js --amount max --env testnet -n hedera -``` +Creating a new HTS token requires a fee paid in HBAR. Because ITS contracts are EVM-based and cannot hold HBAR directly, the ITS implementation on Hedera uses **Wrapped HBAR (WHBAR)** to pay this fee. When deploying a new Interchain Token on Hedera, you must ensure the deploying account has sufficient WHBAR approved for the `InterchainTokenFactory` contract. ### No Initial Supply on Deploy -Deploying a new Interchain Token with an initial supply is **not currently supported** on Hedera. This is because an account must be explicitly associated with an HTS token before it can receive a balance. When a new token is deployed, the deploying account is not automatically associated, so minting an initial supply would fail or result in a gas charge with no tokens received. - -This behavior may be updated in a future version of the `InterchainTokenFactory` contract. +Deploying a new Interchain Token with an initial supply is **not currently supported** on Hedera. This is because an account must be explicitly associated with an HTS token before it can receive a balance. ### Non-Deterministic HTS Token Addresses -Unlike ERC-20 tokens, HTS tokens do not have addresses derived from the deployer's address and nonce. The address assigned to a new HTS token is non-deterministic. After deploying a new Interchain Token on Hedera, retrieve its address by calling: - -```solidity -address tokenAddress = IInterchainTokenService(its).registeredTokenAddress(tokenId); -``` +Unlike ERC-20 tokens, HTS tokens do not have addresses derived from the deployer's address and nonce. After deploying a new Interchain Token on Hedera, retrieve its address by calling `IInterchainTokenService(its).registeredTokenAddress(tokenId);`. ### Token Association Requirement -Before any account or contract can receive an HTS token, it must be **associated** with that token. This is a Hedera-specific requirement with no EVM equivalent. - -If your contract needs to receive ITS tokens (for example, as part of a GMP call that also transfers tokens), it must implement the `InterchainTokenExecutable` interface and associate itself with the token before any transfers occur. One way to do this is: +Before any account or contract can receive an HTS token, it must be **associated** with that token. If your contract needs to receive ITS tokens, it must implement the `InterchainTokenExecutable` interface and associate itself with the token, for example: ```solidity function associateWithToken(address tokenAddress_) external { @@ -207,26 +192,31 @@ function associateWithToken(address tokenAddress_) external { } ``` -The `IHRC719` interface abstracts the HTS precompile, so your contract does not need to interact with the HTS library directly. - ### Unsupported Token Key Types -HTS tokens support several optional key types that control administrative operations. ITS does not support tokens that have the following keys set: - -- `kycKey` -- `wipeKey` -- `freezeKey` -- `pauseKey` - -An `adminKey` can be used to update existing keys, but it **cannot** add new keys if they were not defined when the token was created. +ITS does not support HTS tokens that have the `kycKey`, `wipeKey`, `freezeKey`, or `pauseKey` set. An `adminKey` can be used to update existing keys, but it **cannot** add new keys if they were not defined when the token was created. ### Maximum Supply -The maximum supply for an HTS token is **2^63 − 1**, which is significantly smaller than the 2^256 − 1 maximum for standard ERC-20 tokens. Ensure your token's total supply does not exceed this limit. +The maximum supply for an HTS token is **2^63 − 1**, which is significantly smaller than the 2^256 − 1 maximum for standard ERC-20 tokens. -### HTS Tokens as ERC-20 +### `gasLimit` Workaround for Remote Deployment -HTS tokens support ERC-20 facade methods (`name`, `balanceOf`, `transfer`, `transferFrom`, `approve`, `allowance`) via [HIP-218](https://hips.hedera.com/hip/hip-218) and [HIP-376](https://hips.hedera.com/hip/hip-376). However, `mint` and `burn` are not part of the ERC-20 facade — they are handled directly by the `TokenManager` contract through the HTS precompile. HTS tokens also do not emit `Transfer` events to and from the zero address on mint and burn. +When using Hardhat or a similar framework to call `deployRemoteCanonicalInterchainToken` programmatically, you may encounter a "cannot estimate gas" error. This is a known issue. The workaround is to manually specify a high gas limit in the transaction options: + +```javascript +const tx = await interchainTokenFactoryContract[ + "deployRemoteCanonicalInterchainToken(address,string,uint256)" + ]( + customTokenAddress, + "Avalanche", + gasAmount, + { + value: gasAmount, + gasLimit: 15_000_000 // Manual gas limit + } +); +``` --- @@ -236,16 +226,13 @@ HTS tokens support ERC-20 facade methods (`name`, `balanceOf`, `transfer`, `tran | :--- | :--- | | [Axelar Documentation](https://docs.axelar.dev/) | Full Axelar developer documentation, including GMP and ITS guides | | [ITS Portal](https://interchain.axelar.dev/) | No-code interface for deploying and managing Interchain Tokens | -| [Squid Router](https://www.squidrouter.com/) | Cross-chain swap and bridging platform powered by Axelar ITS | -| [AxelarScan](https://axelarscan.io/) | Block explorer for tracing cross-chain transactions | | [axelar-contract-deployments](https://github.com/axelarnetwork/axelar-contract-deployments/tree/main/hedera) | Deployment scripts and utilities for Hedera ITS contracts | -| [axelar-gmp-tests](https://github.com/skurzyp-arianelabs/axelar-gmp-tests) | GMP example contracts and Foundry scripts for Hedera | | [Hedera ITS contracts (commonprefix fork)](https://github.com/commonprefix/interchain-token-service/tree/hedera-its) | The Hedera-specific fork of the ITS contracts with HTS support | | [HashScan Explorer](https://hashscan.io/) | Hedera network explorer for verifying token deployments and transactions | ## Summary -**Axelar** connects Hedera to a cross-chain ecosystem of 83 networks through two complementary protocols. **ITS** provides a no-code, mint/burn bridge for tokens — eliminating liquidity fragmentation and giving tokens the same address across all connected EVM chains. **GMP** enables arbitrary cross-chain function calls, opening the door to complex multi-chain applications built on Hedera. +**Axelar** connects Hedera to a cross-chain ecosystem of 83 networks through two complementary protocols. **ITS** provides a no-code, mint/burn bridge for tokens, while **GMP** enables arbitrary cross-chain function calls. Because Hedera's token model differs from EVM standards, working with Axelar on Hedera requires attention to HTS-specific details: token association, WHBAR for creation fees, non-deterministic addresses, and supply limits. The [Developer Considerations](#developer-considerations) section above covers each of these in detail. From 3bbc22002bea18a99dd3b5d4339384098d2c9269 Mon Sep 17 00:00:00 2001 From: krystal <56278409+theekrystallee@users.noreply.github.com> Date: Tue, 24 Feb 2026 15:06:42 -0800 Subject: [PATCH 3/3] added axelar integration docs Signed-off-by: krystal <56278409+theekrystallee@users.noreply.github.com> --- docs.json | 5 +++-- .../interoperability-and-bridging/axelar.mdx | 2 -- 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/docs.json b/docs.json index 0789e28c..07c13ebe 100644 --- a/docs.json +++ b/docs.json @@ -576,9 +576,10 @@ "group": "Interoperability and Bridging", "pages": [ "hedera/open-source-solutions/interoperability-and-bridging", + "hedera/open-source-solutions/interoperability-and-bridging/axelar", "hedera/open-source-solutions/interoperability-and-bridging/layerzero", - "hedera/open-source-solutions/interoperability-and-bridging/chainlink", - "hedera/open-source-solutions/interoperability-and-bridging/axelar" + "hedera/open-source-solutions/interoperability-and-bridging/chainlink" + ] }, { diff --git a/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx b/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx index e8d96a5f..0cdcc2c3 100644 --- a/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx +++ b/hedera/open-source-solutions/interoperability-and-bridging/axelar.mdx @@ -3,8 +3,6 @@ title: Axelar description: Learn how Axelar's Interchain Token Service (ITS) and General Message Passing (GMP) integrate with Hedera to enable cross-chain token transfers and arbitrary messaging. --- -import { Card, Cards, Info, Warning } from "mintlify"; - ## What is Axelar? Axelar is a decentralized interoperability network that lets blockchains communicate and transfer assets with each other. It runs its own proof-of-stake chain, where a decentralized set of **57 active validators** verify cross-chain messages and reach consensus before anything is executed on the destination chain. This architecture means there is no single trusted relayer — security comes from the validator set itself.