decimal metadata for use on gravity bridge

[okwme]

This is a topic that came up with @alexanderbez I wanted to highlight for the IBC team. It sounds like there may already be some solutions in place according to @jackzampolin. One thing I was struggling to understand is whether this is a UX problem or a state machine problem. The scenario is as follows:

The gravity bridge uses an ERC20 contract on ethereum to mint representations of Cosmos Coins on Ethereum. ERC20 has string name, string symbol and uint256 decimals as part of the on-chain metadata. The decimals is used to render the uint256 with precision (Eth uses 18 decimals but it varies between ERC20s). Coin types in the Cosmos SDK include similar metadata like string denom and uint32 exponent that provide the contents when deploying the ERC20 (this is where denom = atom and exponent = 6). However when assets come over IBC they no longer have this metadata and so all IBC coins would be deployed with decimal (exponent) = 0. Ethereum interfaces don't know to trace the asset back to Cosmos and then further via IBC.

My biggest question is what is the process of deploying the ERC20 contract on Ethereum? Is this something that the validators come to consensus on and deploy somehow collectively? Is it single validator's responsibility? Is it a user's responsibility? Whoever actually deploys the contract might have the ability to trace the original IBC asset and get the relevant metadata, but it would happen outside the state machine. Not sure if that matters tho since I don't know that part of the process well enough.

[jtremback]

First, a rhetorical question:

Q: What gives an ERC20 that represents a Cosmos token value?
A: What gives it value is that the Cosmos chain is willing to exchange the ERC20 for the underlying Cosmos token.

Now, your question:

My biggest question is what is the process of deploying the ERC20 contract on Ethereum?

The process is as follows:

• Anyone can deploy an ERC20 contract which is supposed to represent a Cosmos token, by calling the DeployERC20 endpoint on Gravity.sol with the denom. The deployer supplies all the values for "name", "symbol", and "decimal".
• The Cosmos chain now checks that the values are what it expects. It will only consider the deployed ERC20 contract valid if it meets all its requirements. In reality, the deployer actually has no control over what "name", "symbol", and "decimal" are. They are more just sponsoring the deployment by paying for gas.
• If all values are correct, the ERC20 is adopted as the representation of that Cosmos token. If anything is wrong, it is ignored and the deployer just wasted some gas.

This can be counterintuitive because people expect the DeployERC20 call to Ethereum to have been generated by the Cosmos module itself. However, this would be an unnecessary step.

Now, to the actual values of those arguments. In an earlier version of Gravity, we tried to match "name", "symbol" and "decimals" to the Cosmos token's metadata. However, this was an unending source of trouble. There isn't a clean correspondence. In my opinion the Cosmos metadata format is bad. Is "Display" a full name, or is it a symbol? Is "Description" the full name, or is it a blurb or something? There's a whole array of possible denominations, which would need to be searched through with certain heuristics to find out which corresponds to the "decimals" field. Worst of all, there are no constraints or guidance on how Cosmos token creators set these fields. Also, on IBC tokens, IIRC most of this stuff isn't set at all.

We have a very simple path when there is no metadata: name = Cosmos denom, symbol = "", decimals = 0. For an IBC token, this will result in an ERC20 with an IBC hashed denom as a name, and 0 decimals, leading to very large numbers being displayed. It will look like crap in most Ethereum wallets, but it is the only thing that can be done. Perhaps in the future, Ethereum wallets and apps can call some sort of endpoint to get the real name, decimals, and maybe symbol from Cosmos.

You can read the procedure here: https://github.com/cosmos/gravity-bridge/blob/main/module/x/gravity/keeper/ethereum_event_handler.go#L91

[alexanderbez]

Thanks @okwme for writting this up! I just want to state that I believe this is entirely a UX problem. Specifically, a UX problem when receiving IBC assets. These assets do not have any metadata on chain unless they're added on the fly, which Umee and Somm do. However, they don't know what exponent(s) to use in the metadata. Hence, when those IBC assets are eventually bridged over to Ethereum, their decimal value by default will be zero and wallets will display very large values.

[alexanderbez]

I'd also like to note that this can be avoided for most "major" or common tokens, e.g. atom, osmo, akash, etc..., by the chain having the metadata already exist at genesis for these tokens. However, this doesn't solve the problem for tokens that are launched later or tokens that are not as popular or common.