IIP: Cross Chain Token Standard

[simusud]

This is a discussion for the CPS proposal to write a Cross Chain Token Standard in order to facilitate seamless migration of existing tokens on ICON and chains connected by ICON GMP to a new cross-chain token standard designed for compatibility and easy integration with Balanced.
The standard has mirrored the operational framework of bnUSD, where minter contracts are deployed across various chains to provide a native user experience. This setup ensures seamless operation and accessibility of our tokens on multiple blockchains.

CPS Proposal link: https://cps.icon.community/proposals/bafybeifgqaddnhqwqnvly6kulxj5vtl4iaprqulezoz25acq6vhwvirn5a

Proposed Token Standard: Cross Chain Token Standard

We would appreciate any input and discussion here before drafting a IIP PR.

[AntonAndell]

This does look good.
One thing i noticed on our frontend devs is that it might be a bit hard to figure out the fees for some actions.
It might be a interesting idea to include a estimateFee type of function to help users figure out the potententail fee for doing a cross chain transfer. It will be up to each implementation on how they do it. but might be good to have a standardized way of displaying it.

One token might not take any ICX but instead takes a %fee to transfer crosschain or perhaps use some expensive protocol takes takes a lot of ICX. Not sure exactly the bset way to do somthing like this. But would be helpful i think

[simusud]

Thank you Anton, for your feedback. That definitely is an interesting feature to add on. We will discuss how it can be implemented.

[dbrehmer]

@AntonAndell - Another thing you mentioned when we spoke was the idea to have a method that would simply report that this is a cross-chain enabled token. That could be really useful for any contract that is handling tokens to be able to determine that.

It gets me thinking one step farther that the method could return a list of enabled chains, and that might require another method that allows the token contract owner to update the list of connected chains. Is that reasonable? It would certainly make the tokens more easily composable.

How about if on deployment of a new spoke token it makes a GMP call back to the hub to register it, then the record of connected chains on the hub would be updated automatically? In that case it might be better recorded as a map with chain IDs as keys and [0, 1] as the value that tells whether it is enabled.