Handle TokenContractAddress in Peggy and deal with duplicate symbols across token addresses

[denalimarsh]

This issue was created due a conversation over in swishlabsco/peggy: swishlabsco#4 (comment)

TokenContractAddress may also be needed in the Denom in order to guarantee coin uniqueness (see comment).

[musnit]

The gist of the conversation is that Cosmos (and so Peggy) don't seem to support 2 different coins which have the same denom. This means that anyone can create an arbitrary ERC20 with the same symbol as an existing one, use Peggy to transfer it over, and so debase a real ERC20 with a fake one.

Is there any way to have two different coins with the same denom in Cosmos at the moment?

Some potential fixes:

• Whitelist hardcoded ERC20 token addresses on the bridge and only support those
• Whitelist the first received ERC20 token address with any given symbol and block future ones with a different address
• Have a validator-voting based whitelist
• Include the token address in the denom, so we have symbol_addressA and symbol_addressB as different denoms
• Add support to Cosmos SDK for different tokens with the same denom

Can we get thoughts from someone on the team for this too?

[okwme]

I'm more a fan of the address prefix. It's my understanding this is similar to how IBC will work. There will be a prefix of the chain_id or some uid representing the chain with some deliminator. It could be ":" or "-", just whatever it is shouldn't be possible to include in the prefix. Client libs would just need to be careful to parse the names of the coin in order to show human readable names instead of long prefixes.

[okwme]

As mentioned in issue #147 keeping track of asset origin would also allow a more united interface.

[denalimarsh]

Closing in favor of #123, #147