Abstract: In this piece, we look at a common problem facing both distributed exchanges and cross-chain atomic swaps: what we call the “inadvertent call option.” Non-custodial fully-distributed trading systems often inadvertently create an American-style call option, rather than the more simple desired operation of exchanging one asset for another. We review how this same issue applies to some specific distributed trading platforms like Bisq and particular cross-chain atomic swaps constructions. We then look at how IDEX solves this problem, but then requires users to trust the platform operator, to some extent, by removing some benefits of distributed exchanges. We conclude that despite the added complexity, in some circumstances it may be better to embrace the call option feature as a viable product, rather than ignoring or fighting it.
Overview
Alongside distributed stablecoins, distributed exchanges (DEXs) are often seen as one of the two holy grails within the cryptocurrency ecosystem. However, similar to distributed stablecoins, the challenges involved in DEXs are often underestimated. In this piece, we focus on one specific challenge with distributed exchange systems: instead of allowing simple exchange, these systems often inadvertently produce American-style call options.
The Theory Of The Inadvertent Call Option
When trading one cryptocurrency asset for another in any fully non-custodial system, one party must act first and the second party must follow. In theory, at some point, this second party then has optionality: – he or she can either follow through and complete the trade, or take no action and stop the trade. In the time interval between the first party taking the necessary action and the second party being required to act, if the price of the token the second actor is attempting to buy falls in value, or the price of the token he is selling increases in value, he could refuse to complete the trade. This means the following:
- The trader who acts first has written an American call option on the spread between the two assets.
- The trader who acts second has purchased an American call option on the spread between the two assets.
These exchanges can either happen atomically or as two separate transfers. Let’s consider Alice buying Bitcoin from Bob, using Litecoin.
Description | Call option problem | |
Atomic trading |
Either both the Litecoin transaction and Bitcoin transaction occur, or both transactions fail (e.g. Cross-chain atomic swaps). | One party must act first and then the second party can decide to execute both trades or not. This decision can be influenced by price changes in any of the two assets in the intervening period. This provides the second party to act with optionality. |
Non-atomic trading |
It is possible for one of the transactions in the trade to succeed and the other to fail. In this case, typically a quasi-custodial mechanism such as multi-signature escrow, is required to prevent cheating for at least one side of the trade (e.g. Bisq-type platforms). |
One party must act first and then the second party can decide to execute his part of the transfer or not. Failing to execute the second transfer could result in either:
Either way, the second party has optionality. |
As the table above illustrates, whether the trading is atomic or not, the same optionality principle applies.
One may think this is an insignificant issue, as the time periods can be short or the option value may be low; however, this is typically not the case: the option period is often around 24 hours and cryptocurrency prices can be very volatile. This high volatility is typically the reason traders wish to exchange the tokens in the first place. Therefore, the option value can be significant and impact trading.
It may be possible to mitigate or solve this problem by using more steps involving more deposits, but we have not yet observed a system achieving this. The other way to mitigate the problem is via the reputation of individual traders and a distributed web of trust-based systems, with traders revealing a form of identity. Traders can then lose reputation if they cancel trades based on price volatility. However, this may greatly increase the complexity of the systems, as functioning sybil attack resistant distributed reputation systems are also challenging to construct.
Below we examine three differently constructed distributed exchange type systems (or quasi DEXs) and explain how the call option problem arises.
Case Studies
Bisq
Summary table
Type | Non-atomic |
Optionality period | 24 hours (up to 8 days) |
Escrow | Multisignature escrow for the trader selling Bitcoin only |
Bisq (previously known as Bitsquare) is a peer-to-peer application, which enables one to buy and sell cryptocurrency with fiat money, as well as trade between crypto-tokens. Bisq is essentially a DEX, as traders connect to each other over a peer-to-peer network and transact with each other directly.
Bisq Daily Trading Volume (USD)
(Source: Coinmarketcap)
Screenshot from the Bisq platform
(Source: BitMEX Research)
Below we explain some examples of potential trading activity on Bisq and describe the resulting options.
Example 1: Acquiring Bitcoin with USD on Bisq
Alice wishes to purchase 1 BTC from Bob, using U.S. dollars:
- Step 1: Bob places 1 BTC in a 2 of 3 multisignature account. The three signatures belong to Bob, Alice, and a third-party arbitrator. This is Bob’s offer, which includes a price (e.g. US$3,800 per BTC).
- Step 2 – Alice can accept Bob’s offer by paying a small refundable deposit into another multisignature account. The fee is set by Bob (e.g. 0.01 BTC).
- Step 3 – Alice has 24 hours to conduct a bank wire transfer, paying US$3,800 into Bob’s account. If there is no dispute and the wire transfer occurs, Alice receives the 1 BTC and her deposit back. If no wire transfer occurs, Alice loses the deposit and the 1 BTC is returned back to Bob. Any dispute is mediated by the third-party arbitrator.
The above represents Alice buying Bitcoin; however, when considering the economic incentives involved, since Alice can back out of the trade with limited consequences, one could consider that, after step 2, she has acquired the following American-style call option:
Call option details |
|
Therefore, when Bob determines the value of the deposit Alice is required to pay, in theory he should consider Bitcoin’s volatility and use options pricing systems to ensure Alice is unable to acquire the option for a cheap price. Based on the prices currently available on Bisq, it appears many of these options are undervalued.
Example 2: Acquiring Bitcoin with Monero on Bisq
Alice wishes to purchase 1 BTC from Bob, using Monero (XMR):
- Step 1 – Bob places 1 BTC in a 2 of 3 multisignature account. The three signatures belong to Bob, Alice, and an arbitrator. This is Bob’s offer, which includes a price (e.g. 80 XMR per BTC).
- Step 2 – Alice can accept Bob’s offer by paying a small refundable deposit and a fee set by Bob (e.g. 0.01 BTC).
- Step 3 – Alice has 24 hours to do an on-chain Monero transfer. If there is no dispute and the transfer occurs, Alice receives the 1 BTC and her deposit back. If no wire transfer occurs, Alice loses the deposit and the 1 BTC is returned back to Bob. Any dispute is mediated by the arbitrator.
Again, the above example may be considered as Alice buying Bitcoin; however, when considering the incentives, since Alice can back out of the trade with limited consequences, one could consider that she has acquired the following American-style call option:
Call option details |
|
If one is trying to capture the benefits of buying a call option with a low premium, this Monero trade may be more beneficial than the U.S. dollar version, since the Monero price is more volatile, and therefore the value of the option is higher. Since the Monero price is more volatile than Bitcoin, it may be more economically correct to conclude that Alice has acquired the following put option, rather than a call option.
Put option details |
|
As a trader, if one wants to take advantage of this structure, one could purchase these Monero puts for a low premium and then hedge the exposure by going long Monero on a centralised platform. However, Bisq has small position limits and therefore the size of the profit-making opportunity is limited.
Although it may make marketing the platform more challenging, it might make Bisq more robust to rebrand these trades as options and encourage sellers of Bitcoin to set the deposit price such that it’s consistent with the premium payment for the equivalent option based on the price volatility of the assets involved, for example by using the Black–Scholes model.
Cross-Chain Atomic Swaps
Summary table
Type | Atomic |
Optionality period | 24 hours (or whatever the parties set as the lock time period) |
Escrow | None |
We believe cross-chain atomic swaps were first described by TierNolan on the Bitcointalk forum in May 2013. Cross-chain atomic swaps allow users to exchange one asset for another atomically, such that the entire process either succeeds or fails. This allows for no risk for either party losing out by only one of the two transfers completing.
The following illustration describes the on-chain atomic swap process. It is based on a swap between Alice and Bob, with Alice exchanging 1 Bitcoin for 100 Litecoin belonging to Bob.
Cross-chain Atomic Swap Construction
# | Actor | Description | ||
1 | Alice | Alice picks a random number X. | ||
2 | Alice | Alice creates a transaction sending 1 BTC to Bob.
Transaction 1 The transaction can be redeemed when either:
| ||
3 | Alice | Alice creates and signs a transaction sending the 1 BTC output of transaction 1, back to herself.
Transaction 2 The transaction is time locked for 24 hours. | ||
4 | Alice | Alice sends transaction 2 to Bob. | ||
5 | Bob | Bob signs transaction 2 and returns it to Alice. | ||
6 | Alice | Transaction 1 is broadcast to the Bitcoin network.
| ||
7 | Bob | Bob creates a Litecoin transaction sending 100 LTC to Alice.
Transaction 3 The transaction can be redeemed when either:
| ||
8 | Bob | Bob creates and signs a transaction, sending the 100 LTC output of transaction 3 back to himself.
Transaction 4 The transaction is time locked for 24 hours. | ||
9 | Bob | Bob sends transaction 4 to Alice. | ||
10 | Alice | Alice signs transaction 4 and returns it to Bob. | ||
11 | Bob | Transaction 3 is broadcast to the Litecoin network.
| ||
At this point, Alice has the optionality. If the LTC/BTC price ratio increases, she could continue the swap process. Or, if the LTC/BTC price ratio falls, Alice can end the process here.
| ||||
12 | Alice | Alice spends the output of transaction 3 to herself, revealing X. Alice now has 100 LTC.
| ||
13 | Bob | Bob spends the output of transaction 1 to himself, using the X Alice provided above. Bob now has 1 BTC.
|
(Source: BitMEX Research)
As the table illustrates, although one is attempting to structure an atomic swap, similar to Bisq, it has inadvertently resulted in an American-style call option. The same issue appears to apply to either multi-currency routing via the lightning network or off-chain lightning-based cross-chain atomic swaps, during the construction of the channels. It could be possible to solve these issues with more steps and a longer series of deposits, although this added complexity may make implementation more challenging. Just as for Bisq above, it may be more appropriate for cross-chain atomic swap developers to embrace the call options and make it the product, rather than to try to brush this problem under the carpet or solve it with added complexity.
IDEX
Summary table
Type | Atomic |
Optionality period | n/a |
Escrow | Partial escrow for both sides of the trade with IDEX, with a sunset clause |
IDEX is an exchange platform using the Ethereum network. Traders deposit funds into an Ethereum smart contract, where the signature of both the traders and the IDEX platform is required to submit orders, execute trades, or make payments.
After a certain time horizon, users can withdraw funds from the smart contract without a signature from IDEX, which protects user deposits in the event that IDEX disappears. Order submission, order cancellation, and order matching is conducted off-chain on the IDEX servers, to allow for a fast and seamless user experience. The events are then submitted in sequence to the Ethereum blockchain and are only valid with a valid signature from the users. Therefore, IDEX is unable to steal user funds or conduct trades without user authorisation.
According to Dex.Watch, IDEX is the global number one Ethereum-based DEX, with an approximate market share of 50%. IDEX-type platforms are in many ways more advanced than the exchanges above as they can solve the call option problem by having both party’s funds partially held in escrow during the trading period.
IDEX Daily Trading Volume ( USD)
(Source: Coinmarketcap.com)
Although IDEX cannot steal user funds or conduct trades without authorisation, the order of events is determined centrally by IDEX. IDEX could fail to execute an order in a timely manner as well as front run orders or fail to execute an order cancellation in a timely manner. Therefore, while users are protected from some risks common in centralised exchanges, in practise they are still exposed to many of the risks most often talked about with respect to typical centralised exchanges. However, we still consider IDEX type platforms to potentially be a significant improvement compared to the fully centralised alternatives. IDEX also has other limitations such as one can only trade Ethereum-based assets and the platform is eventually constrained by Ethereum network capacity.
Conclusion
In some ways Bisq’s model is more ambitious than IDEX and cross-chain atomic swaps. IDEX limits itself to tokens that exist on the Ethereum network while atomic swaps only deal with some cryptocurrencies. In contrast, Bisq attempts to handle fiat currencies such as the U.S. dollar. While solving the call option problem may be possible using Ethereum smart contracts or more complex lightning network constructions, when fiat currency is involved, it may be impossible to solve.
Of course atomic swaps and an IDEX type platform could work with US dollars if there is a working distributed U.S. dollar stablecoin. However, a distributed stablecoin may require a distributed exchange, to provide the price feed. This illustrates how the two holy grails, distributed stablecoins and distributed exchanges, are interrelated. In a catch-22 type situation, each can only function robustly if the other exists.
Without a distributed stablecoin, in our view, when trading fiat currency for cryptocurrency through distributed systems, the use of call options could be inevitable. Bisq is potentially a useful distributed onramp into the cryptocurrency ecosystem; however, rather than trying to solve the call option problem, perhaps Bisq should embrace it. Maybe an effective onramp into the cryptocurrency ecosystem could be via American-style call options. While this mechanism may not be simple, it may be the only way to structure a robust censorship-resistant way in.