Moving Beyond Simple Token Transfers
IBC launched in March 2021 with a single application built on top — fungible token transfers (ICS-20). A few months later, the Cosmos Hub and Osmosis led the go-to-market efforts for this application.
While token transfers have been the bread and butter of blockchain interoperability, we strive to take this primitive a step further.
Interchain composability envisions a future where not only are tokens transferred seamlessly between chains, but also between modules on those chains. While users today can send tokens from one chain to another, they will soon be able to send and specify what to do with those tokens at the destination.
This is achieved by using a memo field within fungible token transfer packets.
What is the memo field and how does it work?
The recent improvements made to ICS-20 token transfers introduces an optional memofield in the FungibleTokenPacketData struct:
This allows for arbitrary data to be passed in as a string along with token transfers. For instance, information such as user action/call-data, number of decimal places, denomination (denom), ticker symbol, and logo can be indicated within the memo field.
Note that the metadata in the memo field is not used within ICS-20 itself, but instead, a middleware or custom CosmWasm contract can wrap around the transfer protocol to parse the metadata and execute custom logic based off of it.
The memo field will be in the ibc-go v6.0.0 release which includes an API-breaking change. In v6.0.0, you can pass in memo as an argument within NewFungibleTokenPacketData as shown here. With versions v2.5, v3.4, v4.2, and v5.1, you can still make use of the memo field — in a non-API breaking way — by assigning a value to memo directly after initializing the NewFungibleTokenPacketData as shown here.
Note: an IBC packet with a non-empty memo field will fail on the destination (upon packet unmarshalling) if the receiving chain is on an ibc-go version other than v6.0.0, v2.5, v3.4, v4.2, or v5.1.
How does this benefit you as an end-user?
If a user today wants to send ATOM from the Cosmos Hub to Osmosis, and then provide liquidity to a pool (or execute other actions such as swap/stake/post tokens as collateral), they have to sign and approve two different transactions — one to send ATOM to Osmosis and then another to add liquidity.
This UX can be considerably improved if the user can send tokens and specify what to do with them on the destination, all in one action.
The newly introduced memo field provides the infrastructure to make this possible. A user will soon be able to send tokens and take some action programmatically (swap, stake, provide liquidity, etc.), effectively allowing multiple transactions to be bundled into one.
The memo field also stands to benefit the packet-forwarding middleware. In the current design, the middleware would read and write data (receiver address) from the packet struct and route packets from an intermediary to the final destination. This workaround is no longer required since the final destination address can be specified within the memo field.
Other ICS-20 improvements
Apart from the addition of the memo field to the transfer packet struct, there have been a couple of other improvements made to ICS-20 such as:
- Returning packet sequence upon
MsgTransferResponse(Dev UX improvement) - Making the
SendTransfermethod private
Conclusion
By allowing for liquidity and arbitrary data to be passed in a single action, the addition of the memo field will significantly change the way users transact and manage assets cross-chain.
Cross-chain composability has always been a core tenet of IBC development. With the adoption of the in-protocol transfer of metadata, more app chains will soon be able to compose between one another to a greater degree.
If you have questions/feedback/critique regarding the topics discussed above, or have any suggestions on improving ICS-20, we encourage you to reach out to us.
Special thanks to the team at Osmosis for their contributions toward implementing the memo field feature.
About the Author:
Adi Ravi Raj works at Interchain GmbH and is the Protocol Analyst for the IBC team.
Shoutout to Susannah Evans and Carlos Rodriguez for the feedback and review.
