Skip to main content
This specification has been reviewed by the Spec Committee, but it is not responsible for maintaining it.

Synopsis

This standard document specifies packet data structure, state machine handling logic, and encoding details for the atomic swap of fungible tokens over an IBC channel between two modules on separate chains.

Motivation

Users may wish to exchange tokens without transferring tokens away from their native chain. ICS-100 enabled chains can facilitate atomic swaps between users and their tokens located on the different chains. This is useful for exchanges between specific users at specific prices, and opens opportunities for new application designs. For example, a token exchange would require only one transaction from a user, compared to multiple transactions when using ICS-20. Additionally, users can minimize trade slippage compared to using a liquidity pool, given there is a willing counter-party.

Definitions

Atomic Swap: An exchange of tokens from separate chains without transferring tokens from one blockchain to another. The exchange either happens or it doesn’t — there is no other alternative. Order: An offer to exchange quantity X of token A for quantity Y of token B. Tokens offered are sent to an escrow account (owned by the module). Maker: A user that makes or initiates an order. Taker: The counterparty who takes or responds to an order. Maker Chain: The blockchain where a maker makes or initiates an order. Taker Chain: The blockchain where a taker takes or responds to an order.

Desired Properties

  • Permissionless: no need to whitelist connections, modules, or denominations.
  • Guarantee of exchange: no occurrence of a user receiving tokens without the equivalent promised exchange.
  • Escrow enabled: an account owned by the module will hold tokens and facilitate exchange.
  • Refundable: tokens are refunded by escrow when a timeout occurs, or when an order is cancelled.
  • Order cancellation: orders without takers can be cancelled.
  • Basic orderbook: a store of orders functioning as an orderbook system.
  • Atomicity: an exchange of one token for another where it is either a total success or a total failure.

Technical Specification

General Design

IBC swap diagram A maker offers token A in exchange for token B by making an order. The order specifies the quantity and price of exchange, and sends the offered token A to the maker chain’s escrow account. Any taker on a different chain with token B can accept the offer by taking the order. The taker sends the desired amount of token B to the taker chain’s escrow account. The escrow account on each respective chain transfers the corresponding token amounts to each user’s receiving address, without requiring the usual IBC transfer. An order without takers can be cancelled. This enables users to rectify mistakes, such as inputting an incorrect price or taker address. Upon cancellation escrowed tokens will be refunded. When making or taking an order, a timeout window is specified in the relayed data packet. A timeout will result in escrowed tokens refunded back. This timeout window is customizable.

Data Structures

Only one packet data type is required: AtomicSwapPacketData, which specifies the swap message type, data (protobuf marshalled) and a memo field.
All AtomicSwapPacketData will be forwarded to the corresponding message handler to execute according to its type. There are 3 types:
where Coin is an interface that consists of an amount and a denomination:
Both the maker chain and taker chain maintain separate order store. Orders are saved in both maker chain and taker chain.

Life scope and control flow

Making a swap

  1. A maker creates an order on the maker chain with specified parameters (see type MakeSwap). The maker’s sell tokens are sent to the escrow address owned by the module. The order is saved on the maker chain.
  2. An AtomicSwapPacketData is relayed to the taker chain where in onRecvPacket the order is also saved on the taker chain.
  3. A packet is subsequently relayed back for acknowledgement. A packet timeout or a failure during onAcknowledgePacket will result in a refund of the escrowed tokens.

Taking a swap

  1. A taker takes an order on the taker chain by triggering TakeSwap. The taker’s sell tokens are sent to the escrow address owned by the module. An order cannot be taken if the current time is later than the expirationTimestamp.
  2. An AtomicSwapPacketData is relayed to the maker chain where in onRecvPacket the escrowed tokens are sent to the taker address on the maker chain.
  3. A packet is subsequently relayed back for acknowledgement. Upon acknowledgement escrowed tokens on the taker chain are sent to the maker address on the taker chain. A packet timeout or a failure during onAcknowledgePacket will result in a refund of the escrowed tokens.

Cancelling a swap

  1. A maker cancels a previously created order. Expired orders can also be cancelled.
  2. An AtomicSwapPacketData is relayed to the taker chain where in onRecvPacket the order is cancelled on the taker chain. If the order is in the process of being taken (a packet with TakeSwapMsg is being relayed from the taker chain to the maker chain), the cancellation will be rejected.
  3. A packet is relayed back where upon acknowledgement the order on the maker chain is also cancelled. The refund only occurs if the taker chain confirmed the cancellation request.

Sub-protocols

The sub-protocols described herein should be implemented in a “Fungible Token Swap” module with access to a bank module and to the IBC routing module.

Port & channel setup

The fungible token swap module on a chain must always bind to a port with the id atomicswap. The setup function must be called exactly once when the module is created (perhaps when the blockchain itself is initialised) to bind to the appropriate port and create an escrow address (owned by the module).
Once the setup function has been called, channels can be created via the IBC routing module.

Channel lifecycle management

An fungible token swap module will accept new channels from any module on another machine, if and only if:
  • The channel being created is unordered.
  • The version string is ics100-1.

Packet relay

sendAtomicSwapPacket must be called by a transaction handler in the module which performs appropriate signature checks, specific to the account owner on the host state machine.
onRecvPacket is called by the routing module when a packet addressed to this module has been received.
onAcknowledgePacket is called by the routing module when a packet sent by this module has been acknowledged.
onTimeoutPacket is called by the routing module when a packet sent by this module has timed-out (such that the tokens will be refunded).
refundTokens is called by both onAcknowledgePacket on failure, and onTimeoutPacket, to refund escrowed tokens to the original owner.

Backwards Compatibility

Not applicable.

Forwards Compatibility

This initial standard uses version “ics100-1” in the channel handshake. A future version of this standard could use a different version in the channel handshake, and safely alter the packet data format & packet handler semantics.

Example Implementations

History

Aug 15, 2022 - Draft written Oct 6, 2022 - Draft revised Nov 11, 2022 - Draft revised All content herein is licensed under Apache 2.0.