IBC: Uniquely identify all tokens by source chain and transfer path

[cwgoes]

All tokens must be uniquely identified by source chain chainID (which must be globally unique) and are non-interchangeable.

If chain A sends x tokens to chain B, chain B can redeem those x tokens back on chain A through IBC.

Which token is which needs to be extremely clear within UI to prevent token spoofing. Also, optionally, governance can maintain a canonical token registry mapping common identifiers (ETH) to full token identifiers including source chain IDs.

Application zones can opt-in to treating two tokens as "equivalent", indicating that they trust both chains (and exposing their correctness to the security of both chains).

Complete IBC transfer paths must be tracked to allow guaranteed redemption on the original source zone.

Receiving chains must choose which sending chains they trust with credit on which tokens and in which amounts (an arbitrary ruleset). For example, the Cosmos Hub will mark specific zones as source zones for specific tokens, while a DEX zone connecting to the Hub might trust the Hub with credit on all tokens. All of this permissioning logic exists as a standard, but separately from the core IBC protocol, which does not identify any chains in particular.

[alexanderbez]

Application zones can opt-in to treating two tokens as "equivalent", indicating that they trust both chains (and exposing their correctness to the security of both chains).

This would imply these two tokens are fungible?

[cwgoes]

This would imply these two tokens are fungible?

Assuming IBC correctness holds, they will be fungible, yes.

[jackzampolin]

Marking this as critical for IBC spec.

[jackzampolin]

The IBC work is now over in the github.com/cosmos/ics repo. Closing this.