ICS 20: IBC fungible token transfer packet specification

[cwgoes]

Will cover:

• Packet specification & encoding for fungible token transfer
• Required interfaces on each chain
• Provided application-layer security guarantees

[cwgoes]

Might be worth doing fairly soon just as an example for explaining protocol usage.

[cwgoes]

Packet will contain:

• Denomination (string)
• Amount (unsigned integer)

Some nontrivial logic to prefix denominations and reason about alternative source paths.

[cwgoes]

edit: When reading, replace root-of-trust hash with connection identifier in the following text.

Thoughts on permissionless denomination tracking across chains, for chains A and B:

• Chain A bank module accepts new connections / channels from any module on another chain.
• Denominations sent from chain B are prefixed with the hash of the root of trust and the name of the counterparty port of B, e.g. 0x1234/bank for the bank module on chain B with root-of-trust hash 0x1234. No supply limits are enforced, but the bank module on chain A tracks the amount of each denomination sent by chain B and keeps it in a store location which can be queried / proven.
• Coins sent by chain A to chain B are prefixed in the same way when sent (0x4567/bank if the bank module is running on a hub with root-of-trust hash 0x4567). Outgoing supply is tracked in a store location which can be queried and proven. Chain B is allowed to send back coins prefixed with 0x4567/bank only up to the amount which has been sent to it.

This design has the following properties:

• Permissionless, no need to whitelist connections, modules, or denominations.
• Symmetric (just swap A and B - they both implement the same logic).
• Allows inflationary tokens (e.g. for proof-of-stake) originating on one chain to be sent to the other.
• Prevents Byzantine-inflation of tokens originating on chain A, on chain A, as a result of chain B's Byzantine behaviour (though any users who sent tokens to chain B are at risk).
• User-unfriendly naming; will need to be managed via a UI or later nameservice module mapping prefixed denominations to common names ("Atom", "Ethereum").

This does not yet handle the "diamond problem", where a user sends a token originating on chain A to chain B, then to chain D, and wants to return it through D -> C -> A - since the supply is tracked as owned by chain B, chain C cannot serve as the intermediary. I don't know whether dealing with that case should be in-protocol or not - it may be fine to just require the original path of redemption (and if there is frequent liquidity on both paths it will work most of the time). Complexities arising from long redemption paths may lead to the emergence of central chains in the network topology (Hubs).