For a token to be valid in NEAR it is required that it has a contract deployed on-chain. This would mean tokens cannot be created dynamically by another contract. This criteria hinders IBC token transfers which require the host environment to have a dynamic means of registering and minting new tokens, that did not exist on chain prior to the IBC transfer.
Some background on IBC
IBC operates using channels and ports open on sovereign block chains. A token transferred from A to B would be identified as {port}/{channel}/{base_denom} when it’s successfully acknowledged on chain B.
Let’s say we have a chain A with a currency denominated as LUA having an ICS20 module deployed with a channel open to a counterpart ICS20 contract on Near.
We can have the channel and port on chain A be channel-0, port transfer and on the counterpart contract channel-1, port transfer
if a transfer of LUA is made from the ICS20 module on chain A to its counterpart on Near. It is expected that when the transfer is acknowledged on the Near contract a token with a denomination of transfer/channel-1/LUA should be registered and it should be recognized as a valid token on the Near blockchain.
In a case where the same module on chain A is connected to chain B with a native token denominated as EVE, with channel-2, port transfer on chain A open to channel-3, port transfer on chain B, if a transfer is made from B to A, when the transfer is successfully acknowledged on A a token with denomination of channel-2/transfer/EVE should be registered on A, if that same token is then transferred to the Near contract specified above, then it should have a denomination of channel-1/transfer/channel-2/transfer/EVE when successfully acknowledged on Near, and this multiple hopping can potentially go on infinitely.
Now we can see that all this is happening dynamically, which brings us to the issue at hand with the Near token standard, it doesn’t seem feasible that we can deploy a new contract for each ibc token transfer that comes with a new denomination, so the question is this, would it be possible for a single contract to host multiple tokens, but still have those tokens available for use in any third party near contract?
Proposed solution
Currently, we do not have any design in mind on how to extend the current standard. We just want to discuss this with the NEAR community and see what alternatives are available.
Alternative solutions
We can whitelist the set of contracts that are deployed in advance. In that way, the IBC module will have to reject those denoms that do not have a pre-deployed contract. This is a feasible solution, but quite insufficient. New tokens are created every time, and having to whitelist them and deploy a contract each time can be expensive and introduce long lead times for users.
Another possibility is to mimic some of the logic of the Solana Token program. There, a master program creates new mint authorities. This is flexible enough, since it will initialize these mint authorities if the token isn’t yet present on-chain.