Avalanche Interchain Token Transfer

10 min readJul 2, 2024

With the introduction of permissionless chains, “Subnets” will now be referred to as“L1s”.

TL;DR

Ava Labs introduces Avalanche Interchain Token Transfer (Avalanche ICTT), a secure and efficient solution for any developer to deploy contracts for transferring tokens on Avalanche. This innovation simplifies the traditionally complex and costly process of creating and auditing smart contracts for token bridging between Layer 1 (L1) blockchains. With pre-built, thoroughly audited, and permissionless smart contracts, Avalanche ICTT enables seamless bridging of tokens like USDC and BTC between various L1s on Avalanche. This enhancement saves time and resources while ensuring security and standardization across cross-chain transactions.

Intro: The Problem With Bridging

In the evolving world of blockchain technology, seamless communication between different blockchain networks is essential. That’s where Teleporter comes in — a cutting-edge cross-chain communication protocol designed to enable Avalanche L1s (formerly known as Subnets) to exchange information effortlessly, akin to how countries trade and communicate.

But Teleporter itself is just the foundation for cross-chain communication. It doesn’t include built-in logic tailored for specific applications. For instance, in order to transfer tokens between L1s on Avalanche, you typically need to hire solidity engineers, have them write the necessary smart contracts, then find an auditor to audit these contracts. This process is costly and time-consuming, often taking several months to complete. On top of that, traditional bridges are often riddled with additional trust assumptions, are not transparent or open by design, and have central points of failure.

To make it more concrete, here are a few examples of things you might want to do and why they are difficult:

You want USDC on your L1, but to do this requires a partnership with Circle, which may take time and resources.
You want BTC across multiple L1s on Avalanche, but this requires each of these L1s to coordinate, agree upon a standard bridging process, then find a third-party provider to implement the contracts.
You want to customize your L1 by using your own ERC-20 as the gas token. This requires partnering with a third-party bridge provider, which will take time, money, engineering resources, and additional trust assumptions.

To enhance the developer experience and to streamline this process, Ava Labs has developed a comprehensive solution.

The Solution: Avalanche Interchain Token Transfer

Avalanche Interchain Token Transfer (Avalanche ICTT) overcomes the traditional drawbacks of bridges by leveraging the underlying technology of Teleporter and Avalanche Warp Messaging. Avalanche ICTT does NOT rely on a small subset of nodes, a central operator, or a multisig for its operation. Instead, it leverages the validator set of the source L1 blockchain, which can consist of an unbounded number of validators. Unlike other existing third-party bridging solutions, Avalanche ICTT does NOT introduce additional trust assumptions — the validators of the L1 are sufficient.

Additionally, Avalanche ICTT simplifies and expedites cross-chain token transfers by reducing the complexities and delays typically associated with bootstrapping: We’ve developed and audited essential smart contracts, ensuring they are secure and ready to use. This means you can focus on what matters most — building and innovating — while Avalanche ICTT handles the intricacies of cross-chain communication.

With Avalanche ICTT, you gain:

Accessibility: Anyone can deploy these contracts — they are completely permissionless and open by design.
Cost Efficiency: No need to invest in extensive development and auditing processes.
Time Savings: Accelerate your project timelines with ready-to-use smart contracts.
Security: Rely on thoroughly audited contracts to ensure your token transfers are secure. Unlike traditional bridges, no additional trust assumptions are introduced.

Several existing and new L1s will soon be integrating Avalanche ICTT via AvaCloud. Among launch partners are prominent names like Lamina1, GoGoPool, and ZeroOne. Experience the ease and efficiency of cross-chain token bridging with Avalanche ICTT and unlock new possibilities for your projects on Avalanche.

How It Works: Technical Overview

The Avalanche ICTT contract is non-upgradeable, providing immutability and ensuring that the contract’s behavior at each address is unchanging. The interface provides a simple, standard process to transfer either an ERC-20 or Native token (token used to pay for transaction fees on the given chain) from a source chain to a destination chain, where it is represented as a new token. This token representation on the destination chain can be an ERC-20 or Native token, allowing users to have any combination of ERC-20s and Native tokens between source and destination chains:

ERC-20 <> ERC-20
ERC-20 <> Native
Native <> ERC-20
Native <> Native

The contracts allow custom logic to be implemented for custom minting, burning, or transfer. As denoted in the repository, the source contract is known as the “Home” contract, and the destination contract is known as the “Remote” contract, so we’ll use these terms going forward.

Some key concepts to understand:

A single “Home” contract can have multiple “Remote” contracts.
A “Remote” contract only interacts with a single “Home” contract.
Each combination of contracts is defined on a per asset basis.
Each L1 can have multiple independent token transfer contracts deployed.

The examples below each illustrate one of the above concepts:

A single USDC “Home” contract on Avalanche C-Chain can connect to multiple USDC “Remote” contracts on various L1s. The “Remote” contracts can either transfer the USDC in as an ERC-20 or as the Native gas token of that L1.
A single “Home” contract holds the collateral for a given “Remote” contract. The “Remote” contract has exactly one “Home”.
Separate “Home” and “Remote” contracts need to be deployed for different tokens, e.g., USDC and AVAX have their own sets.
Since anyone can deploy these contracts, there can be multiple contracts for any given token on an L1. To avoid fragmentation, L1s can enable the Contract Manager Precompile to restrict who can deploy contracts on the L1.

To get started with Avalanche ICTT, check out the Avalanche Starter-Kit, Avalanche Academy course, or deploy your own token transfer contract in the Avalanche CLI by following the instructions. For a no-code approach, L1s can head over to AvaCloud and inquire about interoperability.

Use Cases and Example Flows

Want to understand more about the end-to-end flow? Let’s walk through an ERC-20 <> ERC-20 example for bridging native USDC on Avalanche C-Chain to an L1.

Deploy the ERC-20 “Home” contract on C-Chain, specified for USDC as the asset.
Deploy the ERC-20 “Remote” contract on the desired L1, specified for USDC and mapped to the “Home” contract.
To transfer USDC from C-Chain to the L1:
- USDC is first sent to the “Home” contract on C-Chain, where the USDC is locked in this contract as collateral.
- In a second transaction, the “Remote” contract mints the equivalent amount of USDC on the L1.
To redeem the USDC back to C-Chain, the wrapped USDC on the L1 is burned by the “Remote” contract, then a second transaction releases the USDC locked in the “Home” contract on C-Chain.

Now let’s walk through an ERC-20 <> Native token example for deploying USDC as the Native gas token of an L1.

Instead of deploying a new USDC “Home” contract on C-Chain, the one deployed in step 1 of the previous example can be reused. Recall that a single source contract can have multiple destination contracts.
Obtaining USDC as the native gas token of this L1 is a bit of a chicken/egg problem, as some amount of Native tokens must exist to pay the gas costs for 1) deploying the USDC “Remote” contract, and 2) minting transferred USDC from C-Chain. To get around this, first pre-allocate the L1 with some USDC by sending it an airdrop at genesis. This USDC is effectively valueless at this point because it is not yet collateralized.
Now that the L1 has the USDC airdrop, aka some representation of gas, the Native Token “Remote” contract can be deployed on the L1. As a reminder, make sure to map to the correct “Home” contract when deploying the “Remote” contract.
The last step is to collateralize the “Home” contract on C-Chain by sending it sufficient USDC to 1:1 match the USDC minted on the L1 in the “Remote” contract. Note: Until contracts are collateralized, new tokens cannot be minted on the destination.
Now that the contracts are properly set up, USDC can be minted on the L1 with the Native Minter Precompile. This precompile is simple — it provides the “Remote” contract with the capability to mint Native tokens and send them to a designated recipient address. The “Remote” contract contains logic to ensure that from here onwards, the amount of tokens minted on the destination side (L1) is equal to or less than the USDC collateralized on the source (C-Chain).

One more scenario worth diving into is the multihop case, in which USDC is transferred between two different L1s, neither of which are the “home chain” for USDC.

First, USDC “Remote” contracts must be deployed on both chains — let’s call them L1a and L1b — that are mapped to the same USDC “Home” contract on C-Chain.
Since USDC is not native to either L1s, a multihop is needed, meaning that there are 3 transactions instead of the typical 2:
- USDC is first burned on L1a. A message (notification) is sent to the token’s home chain (in this case, C-Chain).
- C-Chain keeps track of USDC balances across L1s on its “accounting ledger” then forwards a message to L1b to mint the equivalent USDC.
- L1b mints the equivalent amount of USDC.

The main benefit of this design is security and efficiency: the destination contracts only need to trust the source contract, and no asset is wrapped more than once. If L1a were to be hacked, it can’t affect balances on another destination (e.g. L1b), as the source contract always keeps track of how much balance each destination contract has. No asset is wrapped more than once because the maximum number of transactions needed for any given transferred token is 3.

Bonus Content: Advanced Features

One interesting feature included in the contracts is the ability to use the transferred tokens in a smart contract interaction within a single Teleporter message. This feature, known as sendAndCall, decreases the number of user interactions.

For example, let’s say you’re on C-Chain but want to be on L1. You have AVAX currently but ultimately want USDC to be able to engage in the dApp on L1. Traditionally, your workflow would be something like:

Transfer AVAX from C-Chain to L1
Swap AVAX on C-Chain for USDC on L1
Engage in dApp on L1 with USDC

sendAndCall aggregates these steps into one, enhancing the user experience and making it easier to leverage services on the destination chain as any contract can be called. It does so by giving a designated contract permission to spend a portion of your AVAX so that you can conduct the swap and forward the funds to the desired dApp, eliminating the need for multiple separate transactions.

Important Notes

sendAndCall has a fallback mechanism where if the smart contract interaction fails for whatever reason, the tokens will still complete a regular bridging operation, but the assets will be transferred to the recipient address specified by the user. The smart contract for the service would not be holding the tokens or able to spend the tokens since the interaction failed.
A relayer is still needed to deliver tokens between these L1s. You can learn more about setting up a relayer here, or head over to AvaCloud to have a Managed Relayer service.
Avalanche ICTT contracts are non-upgradable and cannot be changed once they are deployed. This provides immutability to the contracts, and ensures that the contract’s behavior at each address is unchanging.
Similarly, Teleporter Messenger is non-upgradeable, but new versions can be deployed and tracked via the Teleporter Registry, which provides applications that use a Teleporter Messenger instance a minimal step process to integrate with new versions of Teleporter Messenger. Note: new versions are registered via off-chain Warp messages, making the Registry a distributed operation.
By default, Avalanche ICTT contracts send Teleporter messages using the latest version available in the Teleporter Registry on each chain. Additionally, there is a Teleporter Manager admin role that can choose a minimum supported Teleporter Messenger contract version. This admin also has the ability to pause the token transfer contract by pausing certain Teleporter Messenger addresses.
It’s important to note that the Teleporter Manager can be set to anything. To avoid any sort of admin functionality altogether, one could set it to “unowned” (i.e. 0x00..01). However, most will consider this feature to be useful when there are new Teleporter Messenger versions. As such, it can be set to a single EOA, a multi-sig contract, or even a contract that uses off-chain Warp messages for authentication (making it as distributed as the validator set of the L1 it’s on). The tradeoff is speed to act in the case of a vulnerability vs centralized control of the contract. It is configurable, and any point along that curve can be chosen for a given use case’s requirements.

Conclusion

Avalanche ICTT represents a significant advancement in cross-chain communication using the Teleporter protocol. By eliminating the need for extensive development and auditing processes, it provides a streamlined, cost-effective, and secure way to manage token transfers across different L1s within Avalanche.

With its permissionless design, immutability, and comprehensive feature set, Avalanche ICTT empowers developers to focus on innovation while ensuring the integrity and security of their projects.

Whether you are looking to transfer ERC-20 tokens, utilize Native tokens, or explore advanced features like sendAndCall, Avalanche ICTT opens up a world of possibilities for your blockchain applications.