#tokens #send #contract #receive #chain #ibc #remote

bin+lib abstract-cw20-ics20

IBC Enabled contracts that receives CW20 tokens and sends them over ICS20 to a remote chain

5 releases (stable)

3.0.0 Jul 11, 2024
2.0.0 May 1, 2024
2.0.0-rc Apr 25, 2024
1.4.0 Apr 15, 2024
1.2.2 Jan 24, 2024

#30 in #receive

Download history 430/week @ 2024-08-31 205/week @ 2024-09-07 167/week @ 2024-09-14 143/week @ 2024-09-21 92/week @ 2024-09-28 50/week @ 2024-10-05 122/week @ 2024-10-12 42/week @ 2024-10-19 55/week @ 2024-10-26 57/week @ 2024-11-02 47/week @ 2024-11-09 198/week @ 2024-11-16 49/week @ 2024-11-23 26/week @ 2024-11-30 72/week @ 2024-12-07 45/week @ 2024-12-14

213 downloads per month
Used in abstract-cw-plus-interfac…

Apache-2.0 and LGPL-3.0

120KB
2K SLoC

CW20 ICS20

This is an IBC Enabled contract that allows us to send CW20 tokens from one chain over the standard ICS20 protocol to the bank module of another chain. In short, it lets us send our custom CW20 tokens with IBC and use them just like native tokens on other chains.

It is only designed to send tokens and redeem previously sent tokens. It will not mint tokens belonging to assets originating on the foreign chain. This is different than the Golang ibctransfer module, but we properly implement ICS20 and respond with an error message... let's hope the Go side handles this correctly.

Workflow

The contract starts with minimal state. It just stores a default timeout in seconds for all packets it sends. Most importantly it binds a local IBC port to enable channel connections.

An external party first needs to make one or more channels using this contract as one endpoint. It will use standard ics20 unordered channels for the version negotiation. Once established, it manages a list of known channels. You can use ts-relayer ibc-setup ics20 command to create these.

After there is at least one channel, you can send any CW20 token to this contract via the receiver pattern. The receive message must contain the channel to send over and the remote address to send to. It may optionally include a custom timeout.

Messages

It only accepts CW20ReceiveMsg from a cw20 contract. The data sent along with that message must be a JSON-serialized TransferMsg:

pub struct TransferMsg {
    /// The local channel to send the packets on
    pub channel: String,
    /// The remote address to send to
    /// Don't use HumanAddress as this will likely have a different Bech32 prefix than we use
    /// and cannot be validated locally
    pub remote_address: String,
    /// How long the packet lives in seconds. If not specified, use default_timeout
    pub timeout: Option<u64>,
}

In addition, it supports directly sending native tokens via ExecuteMsg::Transfer(TransferMsg). You must send exactly one coin denom along with the transfer message, and that amount will be transfered to the remote host.

Queries

Queries only make sense relative to the established channels of this contract.

  • Port{} - returns the port ID this contract has bound, so you can create channels. This info can be queried via wasmd contract info query, but we expose another query here for convenience.
  • ListChannels{} - returns a (currently unpaginated) list of all channels that have been created on this contract. Returns their local channelId along with some basic metadata, like the remote port/channel and the connection they run on top of.
  • Channel{id} - returns more detailed information on one specific channel. In addition to the information available in the list view, it returns the current outstanding balance on that channel, as well as the total amount that has ever been sent on the channel.

IBC Responses

These are defined by the ICS20 spec.

Notably, each Channel has a balance of tokens sent over that channel. If an incoming transfer request comes in for a denom it does not know, or for a balance larger than we have sent, we will return an error in the acknowledgement packet.

Dependencies

~4–18MB
~204K SLoC