---
name: avax-interchain
description: Build Avalanche ICM or ICTT integrations with correct identifiers, authenticated origin and destination execution checks.
---

# Interchain messaging & tokens

Source review: 2026-09-06. Recheck network-dependent facts before use.

1. Identify the layer required: Warp provides validator-signed message primitives; TeleporterMessenger and its registry provide application messaging; ICTT builds token-transfer applications above messaging. Read the matching current source below and pin the release.
2. Record both chains' EVM IDs and Avalanche blockchain IDs. Teleporter destinations use a 32-byte blockchain ID, not the integer returned by `eth_chainId`. Verify source and destination messenger/registry deployments independently.
3. Authenticate the receiving application's expected source blockchain and source sender, in addition to the local messenger. State the trusted source validator set and application/registry upgrade powers. Successful transport alone does not authorize an application action.
4. Provision signature collection, relaying, destination gas and message fees where needed. Represent source submission, delivery and destination execution as separate states. Test delayed delivery, duplicate attempts, insufficient destination gas and receiver failure with bounded retry/recovery behavior.
5. For ICTT, identify home and remote contracts, representation of the asset, registration/collateral requirements, token scaling and gas-asset treatment from the chosen release. Reconcile balances on both sides; the same token symbol is not proof of the same asset.

**Current source location:** the archived `ava-labs/icm-contracts` repository moved into `ava-labs/icm-services`. Resolve deployment information from the maintained package, not an old tutorial.

**Evidence to return:** network-paired deployments, origin checks, message ID, source receipt and destination receipt/state change.

## USDC transfer decision

Treat issuer-native USDC as an ERC-20, not the native gas asset AVAX. ICTT can move its value into a remote representation; that does not make the new token Circle-issued native USDC. If issuer-native delivery is required, check Circle's supported destination and CCTP deployment first. CCTP domain IDs, EVM chain IDs and Avalanche blockchain IDs are separate namespaces.

For ICTT, verify the remote implementation even after registration; permissionless registration is not an endorsement. If using `sendAndCall`, check the application outcome and fallback recipient independently from token delivery.

## Primary sources

- [ICM identifier and delivery example](https://build.avax.network/docs/tooling/interchain-kit/icm-messaging)
- [Teleporter source](https://github.com/ava-labs/icm-services/tree/main/icm-contracts/avalanche/teleporter)
- [ICTT source](https://github.com/ava-labs/icm-services/tree/main/icm-contracts/avalanche/ictt)

- [Circle CCTP deployments and domains](https://developers.circle.com/cctp/references/contract-addresses)

## Model cross-chain execution as explicit states

Write source chain/blockchain ID, authenticated sender, destination blockchain ID, target app, nonce/message ID, fee asset, relayer and receiver version separately. Source acceptance, message delivery, receiver execution and asset availability are different milestones. Record destination evidence before reporting completion.

Make receiver authorization include expected messenger AND original source blockchain/sender. Add replay/idempotency handling, restricted administrative changes and a tested retry path. Relayer absence is a liveness failure, not proof that the source transfer failed or should be duplicated. Do not confuse ICM transport authenticity with business authorization.

For token transfers identify the actual home/remote representation and mint/burn/lock authority. Native USDC, bridged USDC and an ICTT representation are different assets. CCTP domains are not EVM chain IDs or Avalanche blockchain IDs.

Use the intended VM, validator set, deployed messenger/receiver and relayer for integration proof. The seven C-Chain recipes and generic Anvil tests do not establish ICM/ICTT operational compatibility. Preserve that limit in [Testing](../testing/SKILL.md), and show independently pending destination state in [Frontend](../frontend/SKILL.md).