ICS20 Channel Support for IBC hooks and Packet Forwarding Middleware

The Shade Protocol team is working on exciting project to onboard users into Secret Network DeFi using the power of the IBC to extend reach into all of Cosmos and beyond. Our initial focus is SILK token accessibility. Silk is an incredibility powerful financial product that has outperformed the dollar by ~30% over the last couple years in the midst of brutal bear market conditions. But despite its awesome performance, growth of this token has been relatively stagnant and we believe a few of the main causes of this stagnation include: (1) Lack of accessibility on other chains and (2) friction with the privacy requirements of Secret Network. If we are able to solve these problems, then we believe Silk will flourish and spread throughout many other ecosystems which has massive benefits for Secret Network as the underlying infrastructure and engine that powers this stablecoin.

Our goals for this project are for users to be able to…

  1. Buy Silk from any chain in Cosmos (and eventually Ethereum via IBC Eureka)
  2. Hold Silk on any chain
  3. Access Silk yield opportunities (staking, lending, etc.) on Secret Network
  4. No secret network signatures, permits/viewing keys, or SCRT gas required

Through the development process we have been working towards integrating Skip.go API to allow users to easily acquire and hold silk on any chain (#1 and #2 above). However we have hit a few big technical roadblocks and are requesting support from SLABS and Secret Network to accomplish our remaining goals. I will outline these problems below.

Problems:

  1. IBC hooks support for incoming ICS20 tokens
  2. Support of Packet Forwarding Middleware (PFM) in the ICS20 contract for outgoing tokens

IBC hooks support for ICS20 tokens

IBC hooks is a method by which a contract can be executed on incoming token transfers. This feature would allow us to do something such as bridging SILK from the Cosmos Hub into Secret Network (previously bridged off secret and is returning) and immediately stake it to earn yield in the form of dSILK staking derivative. IBC hooks contracts have been successfully deployed to do things such as autowrapping of SCRT into sSCRT. However, we believe there is a gap in support specifically for ICS-20 tokens. The ICS-20 contract deployed on Secret Network is used to send snip20 tokens over IBC without need for unwrapping into a public version. Some examples of ICS-20 bridged tokens include SILK, SHD, stkd-SCRT, and axelar bridged tokens. Native tokens, such as in the case of SCRT and other public wrapped “s” tokens, utilize normal transfer channels rather than ICS-20. So far we have only seen successful IBC hooks on the normal transfer channels.

The port: wasm.secret1tqmms5awftpuhalcv5h5mg76fa0tkdz4jv9ex4 made for transferring SNIP20 tokens in and out of Secret Network will not execute IBC Hooks when the correct memo is passed along with the IBC transfer to a channel made for the port. Instead the SCRT side receive msg includes this error: ‘ABCI code: 3: error handling packet: see events for details’ with no other indication of what’s going wrong. You can find an example of SILK going from the Cosmos hub with a hook message failing in this tx, you’ll have to look at the events on the Secret Network receive msg to see the error. Adding hooks compatibility on the wasm ports would benefit Secret Network immensely.

Packet Forwarding Middleware (PFM) in the ICS20 contracts (for distribution to chains outside secret)

The IBC protocol includes support for multi-chain token transfers via Packet Forwarding Middleware (PFM) . It accomplishes this via use of the memo field in the IBC packet.
We have identified that in the current state, the ICS-20 contract on Secret Network does not support use of a memo meaning that the tokens cannot be forwarded beyond a single chain.

This creates the following user story that is very high friction:

Ethereum user wants to buy Silk using Skip.go and IBC Eureka connection to the Cosmos Hub, and then wants to stake it to earn yield. Tokens are transferred from Ethereum into secret network via IBC routing (ETH → Cosmos Hub → Secret) and using an IBC hook (with the assumption that the ICS20 hooks problem explained in previous section is also solved) is then able to stake their Silk on Secret Network to earn yield in the form of dSILK derivative token. HOWEVER, upon the IBC return route to Ethereum with their dSILK tokens, there is no PFM enabled in the ICS20 contract and therefore tokens can only be moved as far as the Cosmos Hub as a single hop from Secret. The Ethereum user now needs to figure out how to setup a cosmos wallet and buy Atom for gas in order to do anything else with their tokens. This is too much complexity and the user decides not to buy silk because they would prefer to just hold balances on Ethereum.

Previous efforts by SLABS have added a memo supporting PFM specifically the Axelar ICS-20 channel, but due to lack of demand, this code was never tested/merged and no contract migration was performed.

The Shade team has opened a similar PR for the standard ICS-20 contract , but this still requires testing and a contract migration as well.

Conclusion/Request

  1. We would appreciate any investigation into ICS-20 channels and their support for IBC hooks. It is certainly possible that we are doing something wrong on our end and maybe we’re missing something simple here. We have hit quite the roadblock and the error messages are not very helpful.
  2. We would appreciate efforts to complete testing/merge on the above PR for support of PFM in the ICS-20 Contract. The Shade team would be more than happy to offer any assistance with the testing and migration process.

Thanks!
~Austin

4 Likes

SILK, as it becomes a big part of Cosmos will drive a lot of traffic back to Secret Network. Hope we can get these problems fixed as soon as possible :slight_smile:

1 Like