[ACP-141] Interchain Token Transfers

[minghinmatthewlam]

ACP: 141
Title: Interchain Token Transfer  
Author(s): Matthew Lam <https://github.com/minghinmatthewlam>
Status: Implementable
Track: Best Practices
Replaces (*optional): n/a
Superseded-By (*optional): n/a

Abstract

Proposes a best practices standard for token transfers between Avalanche L1s using interchain messaing (ICM) and Teleporter.

[geoff-vball]

Suggested change

The token transferrer contract can be used to transfer multiple source tokens to multiple destination tokens, or can be specified to handle only transfers for one source token. Both approaches have their trade offs. With the approach to transfer multiple source tokens, on destination, the token transferrer contract would need to deploy a new contract for each new source token, likely in the form a wrapped token. The token transferrer can keep track of existing wrapped tokens for specific destination chains, as well as the balances transferred to each. With the wrapped token approach though, the destination tokens wouldn't have custom implementations and features, limiting the functionality of the destination token representation. Security wise with this approach, if you allow any arbitrary ERC20 token to be bridged through the same token transferring contract, it'd be difficult and more prone to vulnerability to have a contract that works with any ERC20 token. With the approach to transfer only one source token in the token transferrer contract, the token bridged to each destination chain can have custom implementations and features, and also can tailor its security to that specific token. However, with the custom destination token representation, the token transferrer contract would need to deploy the contract on destination chain before bridging the token from source. This ACP focuses and advocates for the latter approach, where the token transferrer contract is specified to handle only transfers for one source token, prioritizing security and custom implementations for destination tokens.

The token transferrer contract can be used to transfer multiple source tokens to multiple destination tokens, or can be specified to handle only transfers for one source token. Both approaches have their trade-offs. With the approach to transfer multiple source tokens to one destination, the token transferrer contract would need to deploy a new contract for each new source token, likely in the form of a wrapped token. The token transferrer can keep track of existing wrapped tokens for specific destination chains, as well as the balances transferred to each. With the wrapped token approach though, the destination tokens wouldn't have custom implementations and features, limiting the functionality of the destination token representation. Security-wise with this approach, if you allow any arbitrary ERC20 token to be bridged through the same token transferring contract, it'd be difficult and more prone to vulnerability to have a contract that works with any ERC20 token. With the approach to transfer only one source token in the token transferrer contract, the token bridged to each destination chain can have custom implementations and features, and also can tailor its security to that specific token. However, with the custom destination token representation, the token transferrer contract would need to deploy the contract on destination chain before bridging the token from source. This ACP focuses and advocates for the latter approach, where the token transferrer contract is specified to handle only transfers for one source token, prioritizing security and custom implementations for destination tokens.

[geoff-vball]

Suggested change

For example there are token transferrer contracts on chains A, B, and C, that can directly transfer tokens between each other. If the token transferrer contract on chain A gets compromised, it can mint an extra amount of tokens on chain A to an attacker, and then be used to drain the corresponding tokens on chain B and C. To prevent this, there needs to be some tracking of the balance of tokens on each chain, and each token transfer needs to be checked against the balance that chain holds. This ACP explores the implementation of a "home" token transferrer contract, which will track the balances of tokens on each chain, and all other chains would be referred to as "remote" token transferrer contracts. In order to avoid the shared security across token transffer contracts on different chains, every token transfer needs to be checked against the balance on the home token transferrer. This means that transfers between two remote token transferrers need to be done in two steps, first transferring the tokens from the source remote token transferrer to the home token transferrer, and then transferring the tokens from the home token transferrer to the destination remote token transferrer. "Multi-hop" will be used to describe the two step process of transferring tokens between two remote token transferrers. "Single hop" will be used to describe the direct transfer of tokens between a remote token transferrer and the home token transferrer.

For example there are token transferrer contracts on chains A, B, and C, that can directly transfer tokens between each other. If the token transferrer contract on chain A gets compromised, it can mint an extra amount of tokens on chain A to an attacker, and then be used to drain the corresponding tokens on chain B and C. To prevent this, there needs to be some tracking of the balance of tokens on each chain, and each token transfer needs to be checked against the balance that chain holds. This ACP explores the implementation of a "home" token transferrer contract, which will track the balances of tokens on each chain, and all other chains would be referred to as "remote" token transferrer contracts. In order to avoid the shared security across token transferrer contracts on different chains, every token transfer needs to be checked against the balance on the home token transferrer. This means that transfers between two remote token transferrers need to be done in two steps, first transferring the tokens from the source remote token transferrer to the home token transferrer, and then transferring the tokens from the home token transferrer to the destination remote token transferrer. "Multi-hop" will be used to describe the two step process of transferring tokens between two remote token transferrers. "Single hop" will be used to describe the direct transfer of tokens between a remote token transferrer and the home token transferrer.