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

Data Structures
Only one packet data type is required:AtomicSwapPacketData, which specifies the swap message type, data (protobuf marshalled) and a memo field.
AtomicSwapPacketData will be forwarded to the corresponding message handler to execute according to its type. There are 3 types:
Coin is an interface that consists of an amount and a denomination:
Life scope and control flow
Making a swap
- 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. - An
AtomicSwapPacketDatais relayed to the taker chain where inonRecvPacketthe order is also saved on the taker chain. - A packet is subsequently relayed back for acknowledgement. A packet timeout or a failure during
onAcknowledgePacketwill result in a refund of the escrowed tokens.
Taking a swap
- 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 theexpirationTimestamp. - An
AtomicSwapPacketDatais relayed to the maker chain where inonRecvPacketthe escrowed tokens are sent to the taker address on the maker chain. - 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
onAcknowledgePacketwill result in a refund of the escrowed tokens.
Cancelling a swap
- A maker cancels a previously created order. Expired orders can also be cancelled.
- An
AtomicSwapPacketDatais relayed to the taker chain where inonRecvPacketthe order is cancelled on the taker chain. If the order is in the process of being taken (a packet withTakeSwapMsgis being relayed from the taker chain to the maker chain), the cancellation will be rejected. - 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 idatomicswap.
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).
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
- Implementation of ICS 100 in Go can be found in ibcswap repository.