Swaps using Interledger

We have a cross-chain swaps product built to support OTC desks from end to end (hedgebase.io).
Today, we do swaps using a combination of the cloud + the blockchains we support. We escrow signed transactions on the cloud and release them simultaneously or based on certain rules.

We are thinking of migrating to Interledger and wondering there are built in mechanism for atomic swaps while applying a configurable exchange rate between the participants of the swap. Technically it’s just 2 transfers that need to be atomic.

Apologies if the question is a bit primitive - we are still learning Interledger.

1 Like

Today, we do swaps using a combination of the cloud + the blockchains we support. We escrow signed transactions on the cloud and release them simultaneously or based on certain rules.

Not sure what that means, so I can only speak to the technology, and not if it fits your use case. I’ll give a very detailed answer, because this is probably the most common question I get regarding ILP, and hopefully others can expand on it or reference it when useful.

The one sentance answer

ILP doesn’t do atomic swaps, instead opting for streaming cross chain payments.

What’s the difference?

Cross-chain atomic swaps

  1. Alice and Bob agree to an amount, exchange rate, and expiry (timeout) for a BTC/ETH swap.
  2. Alice signs a message to bob transferring BTC to Bob, conditional on some secret only known to Alice. The transaction is automatically canceled after some period T.
  3. Bob signs a message transferring ETH to Alice, conditional on the same secret. The transaction is automatically cancelled after period T-1.
  4. In the happy case, Alice reveals the secret to Bob, which gives her the right to Bob’s ETH, and gives Bob the right to Alice’s BTC.
  5. In the unhappy case, Alice claims the ETH funds but doesn’t tell Bob. Bob can watch the blockchain, learn the secret at T-1, and claim the BTC before the expiry at T.

In this simple scenario, Alice has what is known as an ‘American call option’. Because she is in control of when the secret is revealed, she can strategically choose to reveal it when the exchange rate goes in her favor, and chose not to reveal it when it does, which costs her nothing.

Cross-chain streaming:

  1. Alice and Bob agree to an amount (X), exchange rate, and slippage for a BTC/ETH transaction.
  2. Alice starts streaming packets (say each packet is worth X/100 for simplicity) to herself through Bob, who credits Alices account (Alice owes Bob money denominated in BTC), and Alice on the receiving side credits Bobs account (Bob owes Alice money denominated in ETH). Each packet has a short timeout window (say 5 seconds for simplicity).
  3. When Alice’s credit limit is reached (again say X/100 for simplicity), she send’s Bob a payment channel claim transferring that amount of BTC to Bob.
  4. When Bob’s credit limit is reached, he sends Alice (on the receiver side) a payment channel claim transferring that amount of ETH to Alice.
  5. When the correct amount has been sent, or the exchange rate slippage is greater than the agreed amount, the stream stops.

If at any time settlements stop occurring, the stream will pause at the credit limit until settlements resume or the stream is cancelled. Thus, in the example given, Alice could lose up to X/100 (1%) of the total amount she was swapping.

When is this useful

Note that all of these constructions are only useful for cases where counterparties have limited trust in each other. If you can trust your counterparty, you should most definitely just send them BTC and trust that they will send you ETH. If they don’t, you should rant about it on Twitter, ruin their reputation, or sue them.

In cases where participants are pseudonymous, or there is no legal or social recourse for dishonesty, atomic swaps and streaming cross chain payments offer the potential for economic activity between actors who otherwise would refuse to transact.


The exclusion of cross-chain atomic swaps in favor of streaming payments was a conscious choice by the designers of ILP to alleviate problems with cross-chain atomic swaps that are outlined here and here.
In economic terms, you can think of atomic swaps and streaming payments as two ways of reaching an equilibrium for exchange. In cross chain swaps, American call options performed by bad actors increase liquidity needed to perform swaps, and thus will raise the equilibrium price of transacting. In streaming payments, users will set a maximum loss equal to the amount of time and fees they are willing to pay. This is because sending smaller packets decreases the amount of potential loss, but increases the time to transact.

What each equilibrium looks like, how effective mitigations for each scenario are, and what use cases each system addresses are entirely speculative at this point. There’s tons of nuance, variations in system design and assumptions, and strongly held opinions beyond this basic outline, but this is hopefully a good overview on the topic.

Other companies and products that are in this design space

Kava (disclosure: that’s me :slight_smile: )


Thanks for the answers @karzak . I’m sure this gets asked a lot so apologies if the question was redundant.

There are several limitations for this approach and we’ve decided to stay away. The hashing algorithm needs to match on all blockchains involved. But mainly because it’s expensive as of now.

We like this because it’s a pragmatic and real-life solution to a stubborn problem.
I am not sure I followed though.

So Alice sends “BTC” packets to herself through Bob? Does this make Bob a connector? If so, Bob would need to support sending BTC no?

Can you elaborate on “credits Bobs account”? on-ledger transaction?
Why credit Bob in ETH when that’s what he wants to trade out?