Rename

[minghinmatthewlam]

Why this should be merged

Rename to follow new avalanche-interchain-token-transfer name

[cam-schultz]

These all point to subnet-evm 0.6.1. I'm not sure what the vulnerability is, but given the large number of Go packages names, my guess it's a recent Go CVE that has since been patched. Since we're upgrading to a newere subnet-evm shortly (and considering none of the critical code is directly dependent), this should be safe to ignore.

[cam-schultz]

A handful of minor nits, but overall looks great. Thanks for making all the renaming changes in one pass - that made it very straightforward to search the entire repo while reviewing.

[cam-schultz]

Can we leave MessageType in the name? REGISTER_REMOTE is not a type of Token transfer, for instance.

[minghinmatthewlam]

changed to TransfererMessage and TransfererMessageType.

[cam-schultz]

These all point to subnet-evm 0.6.1. I'm not sure what the vulnerability is, but given the large number of Go packages names, my guess it's a recent Go CVE that has since been patched. Since we're upgrading to a newere subnet-evm shortly (and considering none of the critical code is directly dependent), this should be safe to ignore.

[feuGeneA]

Seems like we're trying to get rid of "bridge" in favor of "transfer" most places but there are several places it feels incorrect to me:

• "collateral to be transferred"
  • the collateral itself never gets transferred anywhere; it stays on the home
• "to allow for transferring tokens from the TokenHome instance to that new TokenRemote instance"
  • the wrapped tokens remain locked in the home, not actually transferred to the remote
• "transferred back to the TokenHome instance"
• "the asset transferred by their specified home."
  • I think "bridged to" was better.
  • if we do keep "transferred", it should be "transferred from their specified home", not "transferred by".

in one part it says that token balances are transferred to the remote, and I can make sense of that, but to word things as if the actual tokens themselves are transferred to the remote, that feels potentially confusing to me.

is the adoption of the "transfer" concept essential to the idea of this rename? are we trying to abstract the collateral/bridge concept away from the user? I took the user to be a developer building on a platform, who would understand collateral/bridge just fine, and abstracting that away under the guise of "transfer" feels potentially confusing.

if we do want to stick with the "transfer abstraction," maybe there should be a paragraph somewhere in the readme explaining that we're really doing lock-and-mint, but we just call it "transfer."

[bernard-avalabs]

Maybe we can first define what "transfer" means in this context.

Instead of: "The home contract lives on the Subnet where the asset to be transferred exists and locks that asset as collateral to be transferred to other Subnets."

We can define transfer as: "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."

We can further position our description away from bridging terminology by removing "collateral" altogether and simply say "A transfer consists of exporting the asset by locking it in the home contract and importing the asset on the remote Subnet"

[minghinmatthewlam]

I like the idea to define transfer and replaced with Bernard's line. Don't think we need to go further and remove "collateral" though.

[meeshhhh]

Continuing Cam's message, between transferrer and transferer, I would prefer transferrer as it seems like the more widely accepted spelling

[openzeppelin-code]

Rename

Generated at commit: 2689eae5f3ae0df615290d4cc36089d32923b733

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 0 0 1 14 17
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[openzeppelin-code]

Rename

Generated at commit: b87a9155b6f267e5640215dc0891fe0485abe29d

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 0 0 1 14 17
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[openzeppelin-code]

Rename

Generated at commit: c10fcd3bfe192aa1f92f709edb2ebef72a2b8ad8

🚨 Report Summary

	Severity Level	Results
Contracts	Critical High Medium Low Note Total	2 0 0 1 14 17
Dependencies	Critical High Medium Low Note Total	0 0 0 0 0 0

---

For more details view the full report in OpenZeppelin Code Inspector

[bernard-avalabs]

Generally looks good. I added a comment responding to Gene's comment about transferring collateral.

[bernard-avalabs]

Maybe we can first define what "transfer" means in this context.

Instead of: "The home contract lives on the Subnet where the asset to be transferred exists and locks that asset as collateral to be transferred to other Subnets."

We can define transfer as: "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."

We can further position our description away from bridging terminology by removing "collateral" altogether and simply say "A transfer consists of exporting the asset by locking it in the home contract and importing the asset on the remote Subnet"

[bernard-avalabs]

Suggested change

Each token transferer 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 and locks that asset as collateral for futuer transfers 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 transferred by their specified home. The token transferers 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.

Each token transferer 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 and locks that asset as collateral for future transfers 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 transferred by their specified home. The token transferers 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.

[cam-schultz]

Just curious, does the linter still consider this a misspelling?

[minghinmatthewlam]

nope all good now, removed

[cam-schultz]

Suggested change

Each token transferer 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 transferers 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.

Each token transferer 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 transferers 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.

[cam-schultz]

LGTM!