ICS20 (Revision): Add memo string to FungibleTokenPacketData

[thorchain-admin]

---

ics: 20
title: Memo String for FungibleTokenPacketData
stage: Proposed
category: IBC/APP
kind: instantiation
author: devs@thorchain.org
created: July 2021
requires: 20

Synopsis

Allow users to add transactional intent to FungibleTokenPacketData in the form of a 180-bytes string "memo".

Motivation

It's not sufficient to just transfer tokens between users on different chains. Increasingly, cross-chain composability will require modules to begin transferring tokens between each other, and they will need the ability to pass transactional intent (ie, call-data).

THORChain is an example of this. Users must be able to use IBC to send assets as well as state what to do with them. THORChain currently uses on-chain memos to enable cross-chain composability (ie, to do swaps between Bitcoin, Ethereum and more). Nomic also indicate that on-chain commitments (memos) is a solution for their pegged Bitcoin implementation.

Various work-arounds include sending to separate modules, or concatenating the memo on the end of the destination address string, but this is very unwieldy.

The best solution is to simply modify ICS20 to add an optional memo string parameter to the packet data.

Technical Specification

Simply modify the interface to add a memo string.

interface FungibleTokenPacketData {
  denomination: string
  amount: uint256
  sender: string
  receiver: string
  memo:string
}

It can be limited to 180-bytes.

Backwards Compatibility

Since it is optional, clients that don't implement the memo can simply drop it. It may not be necessary to add a new version (ie ics20-2

Forwards Compatibility

180-bytes memo will allow the establishment of cross-chain call data. For example, THORChain use this standard:

function:param1:param2:param3:param4

The receiving module parses the string and separates the parameters. It then delegates it to the appropriate function handler to execute.

Example Implementation

interface FungibleTokenPacketData {
  denomination: atom
  amount: 100000000
  sender: cosmos1tf38ulmsrpe3x0r4glqc68pstufv8p6d5jqcs2tf
  receiver: thor1pstufv8p6d5jqcs2tf38ulmsrpe3x0r4glqc68
  memo:swap:BTC.BTC:bc1tf38ulmsrpe3x08pstufv8p6d5jqcs2tfr4glqc6:12312312:shapeshift:100
}

In this example, the cosmos user is swapping 1 ATOM to BTC on their BTC address, with trade limit protection and 100BP affiliate fees to Shapeshift

Copyright

All content herein is licensed under Apache 2.0.

[cwgoes]

This seems pretty straightforward to me. Any thoughts @AdityaSripal?

[AdityaSripal]

I'm in support of this. Why is the 180 bytes limit necessary or beneficial?

[ethanfrey]

I like the idea as well.
I think some limit on the memo field size is important. Not sure why 180bytes, but I would be against allowing 16KB (or 1 MB) there.

[deuszx]

The example given:

function:param1:param2:param3:param4

defines a function call but ICS20 deals with token transfers only. This limitation allows for mode freedom at other design levels. For example, it makes token transfer cost close to deterministic. If this standard starts supporting arbitrary function calls then the cost of sending the fungible token increases and the cost is covered by the bridge account.

[danwt]

There's no size limit right?

[DimitrisJim]

Spec doesn't dictate a size limit from what I recall, implementations can add one, though.