Merge remote-tracking branch 'origin/main' into upgradeable-poc-merge

.github/ISSUE_TEMPLATE/feature_spec.md

@@ -1,6 +1,6 @@
 ---
 name: Feature specification
-about: Discussion on design and implementation of new features for teleporter-token-bridge.
+about: Discussion on design and implementation of new features for avalanche-interchain-token-transfer.
 title: ""
 labels: enhancement
 assignees: ""

.github/workflows/abi_bindings_checker.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-22.04
 
     steps:
-      - name: Checkout teleporter-token-bridge repository
+      - name: Checkout avalanche-interchain-token-transfer repository
         uses: actions/checkout@v4
         with:
           submodules: recursive

.golangci.yml

@@ -3,15 +3,14 @@
 run:
   timeout: 3m
   tests: true
-  # skip auto-generated files.
-  skip-dirs:
-    - "abi-bindings/go"
-  skip-files:
-    - ".*mock.*"
 
 issues:
   # Maximum count of issues with the same text. Set to 0 to disable. Default is 3.
   max-same-issues: 0
+  exclude-dirs:
+    - "abi-bindings/go"
+  exclude-files:
+    - ".*mock.*"
 
 linters:
   disable-all: true

README.md

@@ -1,27 +1,27 @@
-# Teleporter Token Bridge
+# Avalanche Interchain Token Transfer (ICTT)
 
 ## Upgradeability
 
-The teleporter-token-bridge contracts are non-upgradeable and cannot be changed once it is deployed. This provides immutability to the contracts, and ensures that the contract's behavior at each address is unchanging.
+The avalanche-interchain-token-transfer contracts are non-upgradeable and cannot be changed once it is deployed. This provides immutability to the contracts, and ensures that the contract's behavior at each address is unchanging.
 
 ## Overview
 
-Teleporter token bridge is an application that allows users to transfer tokens between Subnets. The bridge is a set of smart contracts that are deployed across multiple Subnets, and leverages [Teleporter](https://github.com/ava-labs/teleporter) for cross-chain communication.
+Avalanche Interchain Token Transfer (ICTT) is an application that allows users to transfer tokens between Subnets. The implementation is a set of smart contracts that are deployed across multiple Subnets, and leverages [Teleporter](https://github.com/ava-labs/teleporter) for cross-chain communication.
 
-Each bridge instance consists of one "home" contract and at least one but possibly many "remote" contracts. Each home contract instance manages one asset to be bridged out to `TokenRemote` instances. The home contract lives on the Subnet where the asset to be bridged exists and locks that asset as collateral to be bridged to other Subnets. The remote contracts, each of which has a single specified home contract, live on other Subnets that want to import the asset bridged by their specified home. The token bridges are designed to be permissionless: anyone can register compatible `TokenRemote` instances to allow for bridging tokens from the `TokenHome` instance to that new `TokenRemote` instance. The home contract keeps track of token balances bridged to each `TokenRemote` instance, and handles returning the original tokens back to the user when assets are bridged back to the `TokenHome` instance. `TokenRemote` instances are registered with their home contract via a Teleporter message upon creation.
+Each token transferrer instance consists of one "home" contract and at least one but possibly many "remote" contracts. Each home contract instance manages one asset to be transferred out to `TokenRemote` instances. The home contract lives on the Subnet where the asset to be transferred exists. A transfer consists of locking the asset as collateral on the home Subnet and minting a representation of the asset on the remote Subnet. The remote contracts, each of which has a single specified home contract, live on other Subnets that want to import the asset transferred by their specified home. The token transferrers are designed to be permissionless: anyone can register compatible `TokenRemote` instances to allow for transferring tokens from the `TokenHome` instance to that new `TokenRemote` instance. The home contract keeps track of token balances transferred to each `TokenRemote` instance, and handles returning the original tokens back to the user when assets are transferred back to the `TokenHome` instance. `TokenRemote` instances are registered with their home contract via a Teleporter message upon creation.
 
-Home contract instances specify the asset to be bridged as either an ERC20 token or the native token, and they allow for transferring the token to any registered `TokenRemote` instances. The token representation on the remote chain can also either be an ERC20 or native token, allowing users to have any combination of ERC20 and native tokens between home and remote chains:
+Home contract instances specify the asset to be transferred as either an ERC20 token or the native token, and they allow for transferring the token to any registered `TokenRemote` instances. The token representation on the remote chain can also either be an ERC20 or native token, allowing users to have any combination of ERC20 and native tokens between home and remote chains:
 
 - `ERC20` -> `ERC20`
 - `ERC20` -> `Native`
 - `Native` -> `ERC20`
 - `Native` -> `Native`
 
-The remote tokens are designed to have compatibility with the token bridge on the home chain by default, and they allow custom logic to be implemented in addition. For example, developers can inherit and extend the `ERC20TokenRemote` contract to add additional functionality, such as a custom minting, burning, or transfer logic.
+The remote tokens are designed to have compatibility with the token transferrer on the home chain by default, and they allow custom logic to be implemented in addition. For example, developers can inherit and extend the `ERC20TokenRemote` contract to add additional functionality, such as a custom minting, burning, or transfer logic.
 
-The token bridge also supports "multi-hop" transfers, where tokens can be transferred between remote chains. To illustrate, consider two remotes _R<sub>a</sub>_ and _R<sub>b</sub>_ that are both connected to the same home _H_. A multi-hop transfer from _R<sub>a</sub>_ to _R<sub>b</sub>_ first gets routed from _R<sub>a</sub>_ to _H_, where remote balances are updated, and then _H_ automatically routes the transfer on to _R<sub>b</sub>_.
+The token transferrer also supports "multi-hop" transfers, where tokens can be transferred between remote chains. To illustrate, consider two remotes _R<sub>a</sub>_ and _R<sub>b</sub>_ that are both connected to the same home _H_. A multi-hop transfer from _R<sub>a</sub>_ to _R<sub>b</sub>_ first gets routed from _R<sub>a</sub>_ to _H_, where remote balances are updated, and then _H_ automatically routes the transfer on to _R<sub>b</sub>_.
 
-In addition to supporting basic token transfers, the token bridge contracts offer a `sendAndCall` interface for bridging tokens and using them in a smart contract interaction all within a single Teleporter message. If the call to the recipient smart contract fails, the bridged tokens are sent to a fallback recipient address on the destination chain of the transfer. The `sendAndCall` interface enables the direct use of bridged tokens in dApps on other chains, such as performing swaps, using the tokens to pay for fees when invoking services, etc.
+In addition to supporting basic token transfers, the token transferrer contracts offer a `sendAndCall` interface for transferring tokens and using them in a smart contract interaction all within a single Teleporter message. If the call to the recipient smart contract fails, the transferred tokens are sent to a fallback recipient address on the destination chain of the transfer. The `sendAndCall` interface enables the direct use of transferred tokens in dApps on other chains, such as performing swaps, using the tokens to pay for fees when invoking services, etc.
 
 A breakdown of the structure of the contracts that implement this function can be found under `./contracts` [here](./contracts/README.md).
 
@@ -38,7 +38,7 @@ A breakdown of the structure of the contracts that implement this function can b
 
 ## Structure
 
-- `contracts/` is a Foundry project that includes the implementation of the token bridge contracts and Solidity unit tests
+- `contracts/` is a Foundry project that includes the implementation of the token transferrer contracts and Solidity unit tests
 - `scripts/` includes various bash utility scripts
 - `tests/` includes integration tests for the contracts in `contracts/`, written using the [Ginkgo](https://onsi.github.io/ginkgo/) testing framework.
 
@@ -93,22 +93,22 @@ Then run the following command from the root of the repository:
 
 ### Run specific E2E tests
 
-To run a specific E2E test, specify the environment variable `GINKGO_FOCUS`, which will then look for test descriptions that match the provided input. For example, to run the `Bridge an ERC20 token between two Subnets` test:
+To run a specific E2E test, specify the environment variable `GINKGO_FOCUS`, which will then look for test descriptions that match the provided input. For example, to run the `Transfer an ERC20 token between two Subnets` test:
 
 ```bash
-GINKGO_FOCUS="Bridge an ERC20 token between two Subnets" ./scripts/e2e_test.sh
+GINKGO_FOCUS="Transfer an ERC20 token between two Subnets" ./scripts/e2e_test.sh
 ```
 
 A substring of the full test description can be used as well:
 
 ```bash
-GINKGO_FOCUS="Bridge an ERC20 token" ./scripts/e2e_test.sh
+GINKGO_FOCUS="Transfer an ERC20 token" ./scripts/e2e_test.sh
 ```
 
 The E2E tests also supports `GINKGO_LABEL_FILTER`, making it easy to group test cases and run them together. For example, to run all `ERC20TokenHome` E2E tests:
 
 ```go
-	ginkgo.It("Bridge an ERC20 token between two Subnets",
+	ginkgo.It("Transfer an ERC20 token between two Subnets",
 		ginkgo.Label(erc20TokenHomeLabel, erc20TokenRemoteLabel),
 		func() {
 			flows.ERC20TokenHomeERC20TokenRemote(LocalNetworkInstance)

SECURITY.md

@@ -18,4 +18,4 @@ Please use the most recently released version to perform testing and to validate
 
 ## Audit Reports
 
-All complete audit reports for `teleporter-token-bridge` can be found in the [audits](./audits/) directory.
+All complete audit reports for `avalanche-interchain-token-transfer` can be found in the [audits](./audits/) directory.