The Arwen Trading Protocols∗

Ethan Heilman, Sebastien Lipmann, Sharon GoldbergVersion 1.0, January 28, 2019

ABSTRACTThe Arwen Trading Protocol is a layer-two blockhchainprotocol that allows traders to securely trade cryptocur-rencies at a centralized exchange, without ceding cus-tody of their coins to the exchange. Before trading be-gins, traders deposit their coins in an on-blockchain es-crow, rather than in the exchange’s wallet. The agent ofescrow is the blockchain itself. Each individual trade isbacked by the coins locked in escrow. Each trade is fast,because it happens off-blockchain, and secure, becauseatomic swaps prevent even a hacked exchange from tak-ing custody of a trader’s coins. Arwen is designed towork even with the “lowest common denominator” ofblockchains—namely Bitcoin-derived coins without Seg-Wit support. As a result, Arwen supports essentiallyall “Bitcoin-derived” coins, including BTC, LTC, BCH,ZEC as well as Ethereum and ERC-20 tokens.

1. INTRODUCTIONThe promise of blockchain-backed cryptocurrencies is

the ability to transact in digital assets without rely-ing on a single trusted party. Blockchains thereforepresent a technical breakthrough that circumvents along-standing result in cryptography: namely, that atomicswaps are impossible without the help of a trusted thirdparty [26]. In an atomic swap, two parties that do nottrust each other swap items, such that either (1) bothAlice gets Bob’s item and Bob gets Alice’s item, OR (2)neither Bob nor Alice gets the other party’s item. Infact, atomic swaps of digital assets are possible whenthe blockchain acts as the trusted third party [7].

Fully realizing the promise of blockchain-backed cryp-tocurrencies demands that atomic swaps be broughtinto the mainstream. Today, we still live in a worldwhere the vast majority of cryptocurrency trading re-quires traders to trust either each other, or a centralizedcryptocurrency exchange. This seems absurd. Much ofthe value of a blockchain-backed cryptocurrency followsbecause it does not rely on a single trusted party. Why,then, is a single trusted party still required when tradingcryptocurrency?

The Arwen Trading Protocol seeks to deliver on this

∗Major contributions to the design of these protocolswere made by James Dalessandro, Ezequiel GomesPerez, Haydn Kennedy, Yuval Marcus, Chet Powers,Omar Sagga, Aleksander Skjolsvik and Scott Sigel.

promise by bringing atomic swaps to the mainstreamuse case of cryptocurrency trading. With Arwen, traderscan benefit from the liquidity at a centralized cryptocurrency-to-cryptocurrency exchange without trusting the exchangewith custody of their coins. Instead, Arwen tradersmaintain custody of their cryptographic keys and theircoins, and Arwen trades are backed by on-blockchain es-crows. Each coin’s native blockchain acts as the agent ofescrow (i.e., the agent of escrow for bitcoins is the Bit-coin blockchain). Arwen trades are fast because theyhappen off blockchain, and secure, because they areatomic swaps. Arwen ensures that even a compromisedexchange cannot steal a trader’s coins, and that a mali-cious user cannot grief or steal coins from the exchange.

Arwen is designed to align incentives for the trad-ing use case, and to support trading instruments fromtraditional financial markets. Arwen is focused on thecross-blockchain trading use case, Arwen must supportas many coins as possible. For this reason, the Arwenprotocols are designed to work even with the “lowestcommon denominator” of Bitcoin-derived coins withoutSegWit [39] support. As a result, Arwen supports es-sentially all “Bitcoin-derived” coins, including Bitcoin(BTC), Litecoin (LTC), Bitcoin Cash (BCH), Zcash (ZEC)),etc.as well as Ethereum and ERC-20 tokens.

2. WHITHER ATOMIC SWAPS?There has been a flurry of activity that seeks to bring

cross-blockchain atomic swaps to the mainstream. Across-blockchain atomic swap allows one cryptocurrency(e.g., Bitcoin (BTC)) to be atomically swapped for an-other cryptocurrency (e.g., Bitcoin Cash (BCH)). Nev-ertheless, there are number of subtle issues that preventknown solutions from seeing widespread adoption forcryptocurrency trading. We now highlight several ofthese issues, and explain how Arwen overcomes them.

2.1 The promise of atomic swaps.Cross-blockchain atomic swaps seek to supplant to-

day’s dominant form of cryptocurrency trading: cus-todial trading at centralized cryptocurrency exchanges.With custodial trading, when users wish to trade on acentralized exchange, they must first deposit their coinsat the exchange; this is done using an on-blockchaintransfer of coins from the user’s own wallet to the ex-change’s wallet. Trading occurs within the databasesof the centralized exchange, and is not recorded on the

1

blockchain. Finally, once trading is complete, users re-gain custody of their coins by withdrawing their coinsfrom the exchange; that is, the exchange uses an on-blockchain transaction to transfer coins from the ex-change’s wallet back to the user’s wallet. Custodialtrading at a centralized exchange exposes the user toserious counterparty risk—if the exchange is compro-mised, the exchange may be unable to transfer coin backto the user’s wallet. This risk has been realized, start-ing with the hack of Mt. Gox [38] and affecting severalcentralized exchanges, e.g., [10, 30, 16, 8, 24, 12, 18,17, 31, 6, 40].

With cross-blockchain atomic swaps, a user would nolonger need to trust a centralized exchange with custodyof her coins. Instead, the user could maintain custodyof her coins even while she trades, and the user’s coinswould not be at risk even if her counterparty becomesadversarial in the middle of a trade.

In an atomic swap of 1 BTC for 20 BCH, it is cryp-tographically guaranteed that: (1) if the Alice trans-fers her 1 BTC to her counterparty, even a maliciouscounterparty cannot prevent Alice from claiming her 20BCH, and (2) if the counterparty transfers his 20 BCHto Alice, even a malicious Alice cannot prevent the coun-terparty from claiming his 1 BTC.

Atomic swaps are an even stronger security paradigmthan “second send” protocols such as ShapeShift. Ina ShapeShift trade, Alice first transfers her 1 BTC toShapeShift’s wallet, and then ShapeShift transfers 20BCH to Alice’s wallet. This is not an atomic swap, be-cause an adversarial ShapeShift could always decide tokeep Alice’s 1 BTC without paying out her 20 BCH.Thus, while such “second send” protocols are sometimesreferred to as non-custodial, they in fact have brief win-dow of custody.

2.2 The challenge of providing liquidity.Most decentralized exchange (DEX) protocols, includ-

ing EtherDelta [1], 0x [37], and SparkSwap [4], are peer-to-peer trading systems, where each trade involves atransfer of funds directly from trader Alice’s wallet totrader Bob’s wallet. The peer-to-peer approach limitsliquidity, because it means that Alice can only tradewith traders that use that same peer-to-peer tradingsystem. If a system has too few users, it will not beable to provide good liquidity.

Arwen eschews the peer-to-peer approach because, to-day, the best liquidity for cryptocurrency trading can befound at centralized exchanges. With Arwen, Alice canbenefit from the liquidity at a centralized exchange evenif she is the only Arwen user at the exchange. This fol-lows because Arwen trades only involve the movementof coins from the user’s wallet to the exchange’s wallet,without the involvement of any intermediaries. In otherwords, Arwen can be thought of as a secure settlementleg for the centralized exchange. Meanwhile, orders arepriced as usual, using the centralized exchange’s exist-ing orderbook.

2.3 The pitfalls of on-blockchain protocols.Some of the best-known atomic swaps protocols are

on-blockchain protocols, where the swap does not actu-

ally execute until certain transactions are confirmed bythe blockchain.

Ethereum DEX protocols. Ethereum DEX pro-tocols, including EtherDelta [1] and 0x [37], use theEthereum blockchain to trade one ERC-20 token for an-other ERC-20 token. Both EtherDelta and 0x uses thefollowing protocol framework. First, Alice broadcastsan order to the network without identifying a counter-party. Some counterparty Bob then sees Alice’s broad-cast, decides to trade with Alice, adds his informationto the order. Bob then posts the order to the Ethereumblockchain, where it is then executed by a smart con-tract on the Ethereum blockchain.

The Bitcoin TierNolan Protocol. The TierNolanprotocol [34] is the original Bitcoin-compatible atomicswap; it can also be used for cross-blockchain atomicswaps for “Bitcoin-like” blockchains (e.g., BCH, LTC,ZEC, etc.). TierNolan uses Hashed Time-Locked Con-tract (HTLC) smart contracts as follows.

Bob chooses a random solution x and computes a puz-zle y, where y = H(x) and H is a cryptographic hashfunction. Bob reveals the puzzle y to Alice and keepsthe solution x secret. Next, Alice locks up 1 BTC in anHTLC smart contract on the Bitcoin blockchain whichstipulates: “before time τA, the 1 BTC can be claimedby a transaction signed by Bob containing the solutionto puzzle y”. Bob similarly locks up 100 LTC on theLitecoin blockchain in an HTLC, which stipulates: “be-fore time τB, the 100 LTC can be claimed by a transac-tion signed by Alice containing the solution to the puzzley”. The atomic swap executes when Bob reveals the xor when he claims the 1 BTC by signing and posting atransaction to the Bitcoin blockchain that contains thesolution x. (For convenience, we will call this a solvetransaction.) Once this happens, Alice learns the so-lution x from the Bitcoin blockchain and can sign andpost a solve transaction to the Litecoin blockchain thatclaims Bob’s 100 LTC.

Security follows from the cryptographic hash functionH (which ensures that no one can learn the solution xgiven only the puzzle y) and the fact that Bob mustreveal x on the blockchain in order to claim his coins.

There are several issues with on-blockchain protocols.

Speed. On-blockchain execution is slow, because it islimited by the speed at which the blockchain confirmsblocks. The expected time to confirm a single block isabout 10 minutes for Bitcoin (BTC) and Bitcoin Cash(BCH), 2.5 minutes for Litecoin (LTC) and 15 secondsfor Ethereum (ETH). Moreover, a single confirmation isoften insufficent to ensure that a transaction can not bereversed [13]; for instance, the cryptocurrency exchangeKraken waits 6 confirmations (60 minutes) for BTC and30 confirmations for ETH (6 minutes) [19]. Even a fewseconds of latency can be problematic when trading,especially given that cryptocurrency prices are famouslyvolatile. An atomic swap protocol that is compatiblewith high-frequency trading strategies must ensure thattrades execute instantly.

Scalability. If each individual trade needs to be con-firmed on the blockchain, and a healthy trading ecosys-tem leads to many trades, then the blockchain itself

2

will be clogged up with transactions resulting from eachindividual trade. Note that today’s custodial tradingecosystem avoids this problem, since the only transac-tions that need to be confirmed on the blockchain cor-respond to deposit and withdrawal of coins from theexchange. To avoid clogging the blockchain, an atomicswap protocol should require the blockchain to confirmonly the consolidated balance across multiple trades.

Front-running. The EtherDelta and 0x protocolsrequire the trader to broadcast information about thetrade to all nodes on the blockchain before the trade isexecuted by the blockchain. This can lead to race con-ditions. Any blockchain node can learn the details ofAlice’s trade with Bob, and attempt to profit from it byfront-running Bob’s trade with its own trade [37]. Theseprotocols also allow a trader to cancel a order (e.g., dueto changing market conditions) by posting a cancella-tion request the blockchain. The on-blockchain natureof this cancellation is also subject to race conditions, be-cause a blockchain node Charlie could add himself as acounterparty to Alice’s order before the blockchain hasa chance to cancel it. These race conditions, however,are avoided by the TierNolan protocol because Alice andBob are required to identify each other counterpartiesat the moment that they lock up coins in the HTLCsmart contract.

The Arwen Trading Protocol avoids speed and scal-ability pitfalls, because individual trades execute off-blockchain. Arwen also avoids the front-running prob-lem by building trading instruments that complementthe puzzle approach pioneered by TierNolan; see Sec-tion 2.6.

2.4 Trading in a layer-two protocolBecause Arwen atomic swaps are executed entirely

off-blockchain, Arwen falls into the same class of blockchainlayer-two protocols [25] as the Lightning Network [29].

In a blockchain layer-two protocol, parties first lockup their coins in an on-blockchain smart contract. Thecoins locked in the smart contracts are then transferredbetween the parties via off-blockchain interactions. Fi-nally, the smart contract is closed on the blockchain, re-flecting the parties’ balance, consolidated across all theoff-blockchain transfers. Blockchain layer-two protocolsare fast, because coins are moved off-blockchain, andscalable, because only consolidated balances are postedto the blockchain.

Arwen escrows. Arwen’s on-blockchain smart con-tracts are called escrows. Before trading begins, Al-ice deposits her coins in an on-blockchain user escrow,where the agent of escrow is the blockchain itself. Theexchange also deposits coins in an on-blockchain ex-change escrow, to prove to Alice that the exchange holdsenough coins to collateralize its trades. Each exchangeescrow is specific to a single user (i.e., Alice) and a sin-gle coin (e.g., Bitcoin Cash). Escrows are opened andclosed by confirming a transaction on the coin’s nativeblockchain. (So, to open a Bitcoin Cash exchange es-crow for Alice, the exchange confirms a transaction onthe Bitcoin Cash blockchain.)

Multiple fast off-blockchain atomic-swap trades can

be executed against a given pair of escrows. Thus, ifAlice wanted to trade 1 BTC for 20 BCH, Alice tradewould be backed by Alice’s user escrow for Bitcoin, andAlice’s exchange escrow for Bitcoin Cash. If Alice hasmultiple open user escrows with a given exchange (e.g.,a user escrow for BTC and a user escrow for ZEC), Alicecan pair them with any of her open exchange escrows(e.g., an exchange escrow for BCH and an exchangeescrow for ETH). This way, Alice can trade across mul-tiple currency pairs (BTC-BCH, BTC-ETH, ZEC-LTCand ZEC-ETH).

To compensate the exchange for locking its coins inescrow, Alice pays an escrow fee each time the exchangefunds an exchange escrow for her. The exchange couldfund exchange escrows from its own inventory of coins.Alternatively, the exchange could fund exchange escrowsusing deposits provided by custodial users of the ex-change, and pay these custodial users a part of the es-crow fee. This creates a new interest-bearing featurethat the exchange can offer to its custodial users.

Arwen vs. the Lightning Network. While Light-ning is designed for the use case of fast peer-to-peerBitcoin micropayments, Arwen is designed for the usecase of cryptocurrency trading. Arwen therefore avoidssome of the incentive issues that result when layer-twomicropayment systems (like Lightning) are repurposedto enable large value trades via atomic swaps.

In the Lightning Network, Alice, Bob and any in-termediate nodes on the path first lock their coins inon-blockchain smart contract—one smart contract forevery consecutive pair of nodes on the path—and thenmove coins along the path via a series of off-blockchainatomic swaps. Arwen does not use a path of interme-diate nodes; instead, coins are transferred only betweenAlice and the exchange. This eliminates the risk thatan intermediate node will strategically disrupt a tradein order to manipulate market prices.

Lightning only works with blockchains that have Seg-Wit support; such as only Bitcoin and Litecoin. Arwendoes not require SegWit support. This means that Ar-wen works with more “Bitcoin-derived” blockchains, in-cluding both coins with SegWit support and coins whichhave not deployed SegWit such as Bitcoin Cash, Zcash,and others. Technically speaking, supporting “Bitcoin-derived”blockchains that lack SegWit requires Arwen towithstand transaction malleability attacks, as discussedin Section 7. Arwen also has support for Ethereum andERC-20 tokens [36], as discussed in Section 6.

2.5 Dealing with lockup griefing.Lockup griefing affects any protocol that requires users

to lock coins in a smart contract. We describe the prob-lem, and explain how Arwen solves it via reputation anda novel escrow fee mechanism.

Lockup griefing in TierNolan. In the TierNolanprotocol, Alice’s coins and Bob’s coins are locked intheir smart contracts until either (1) the trade executesor (2) the timelock on the smart contract expires attime τ . These timelocks τA, τB must at least as longas the time it takes to reliably confirm transactions onthe blockchain, i.e., several hours. The fact that coins

3

must locked for a long time can creates “lock-up grief-ing” problem, where Alice locks her coin in her smartcontract, but Bob refuses to lock his own coins. Alice’scoins are thus pointlessly locked in the smart contractuntil it expires at time τA. (Alice could similarly launcha lockup-griefing attack on Bob.) TierNolan lacks amechanism to incentivize Alice and Bob to avoid lockupgriefing. This is especially problematic when Alice andBob are two random people that met over the Internet.

Lockup griefing in Lightning. Lightning nodesearn fees for transfers of coins across their channel; how-ever, if no transfer of coins occurs, no fees will be earned,which can lead to lockup griefing. Worse yet, a node onthe Lightning path between Alice and Bob could alsodecide to strategically close its smart contract, breakingthe path from Alice to Bob. The makes it risky to useLightning for very high-value trades, where the incen-tive to disrupt a trade can be very significant. This riskis further exacerbated by the fact that Alice and Bobmay have no relationship with the intermediate nodeson the Lightning path.

Using reputation to avoid lockup griefing. Ar-wen sidesteps the risk of lockup griefing because itsinteractions only involve the trader Alice and the ex-change, rather than a peer Bob or a path of intermediatenodes. The exchange has no incentive to launch a lockupgriefing attack against Alice; such an attack harms theexchange’s reputation, and prevents Alice from trading,which is the exchange’s main source of revenue.

Using escrow fees to avoid lockup griefing. Theexchange, however, must protect itself from lockup grief-ing by a trader Alice, who might ask the exchange tolock up coins in exchange escrows willynilly, withoutactually executing any trades against those exchangeescrows. Arwen therefore requires Alice to lock up herown coins in a user escrow before she can ask the ex-change to lock up its own coin in an exchange escrow.Arwen also introduces a novel escrow fee mechanism (seeSection 3.5) that compensates the exchange for lockingup coins for Alice. Arwen’s escrow fees are an in-bandmechanism designed to avoid the introduction of out-of-band payments or of a superfluous fee token. The mech-anism generates revenue for the exchange from locked-up coins, while encouraging the user to close her ex-change escrows (and unlock the exchange’s coin) in atimely manner once she is done trading.

2.6 Atomic swaps as trading instruments.The vision behind Arwen is to use atomic swaps in

traditional trading instruments. For this reason, Ar-wen is specifically designed to avoid a misalignment ofincentives. We’ve already discussed how Arwen alignsincentives when opening and closing escrows; we nowfocus on the incentives involved in trading.

To understand the importance of designing the incen-tive structure used in trading instruments, we returnagain to the TierNolan protocol.

TierNolan as an American call option. TheTierNolan Protocol is asymmetric, because only Bobchooses and knows the secret solution x. This meansthat Bob has the unilateral ability to decide whether

or not the atomic swap executes, by revealing x (ornot). Because the timelocks τA, τB on the smart con-tracts must at least as long as the time it takes to con-firm transactions on the blockchain, Bob has minutesor hours to decide whether market conditions justifythe execution of the swap (or not). This means that theTierNolan Protocol is actually an American call option:namely, Bob has the right, but not the obligation, tobuy 1 BTC from Alice at a strike price of 100 LTC, anytime before the expiry time τ . Typically, the asymme-try in an option is handled by requiring Bob to pay apremium to Alice before the option is set up. However,in the TierNolan Protocol, Bob gets the option for free,resulting in a misalignment of incentives.

This American call option is implicit in many atomicswap protocols. For instance, it exists whenever theLightning Network is used for peer-to-peer trading be-tween Alice and Bob. By contrast, Arwen swaps areexplicitly designed to support different trading instru-ments. The first version of Arwen supports Request ForQuote (RFQ) trading instrument, while limit orders arenext on the Arwen roadmap.

RFQ trading with Arwen. Arwen’s RFQ tradinginstrument is a off-blockchain atomic swap. In an RFQtrade, the exchange commits to a price, called the quote,before Alice decides whether or not to place an order forthe trade. (Request: “How many BCH can I buy for 2BTC?” Quote: “You can buy 40 BCH, quote open for 1second”) If Alice places the order before quote expires,Alice cannot back out of the trade and the exchange isexpected to execute a trade (of exactly 2 BTC for 40BTC). Importantly, RFQs are inherently asymmetric,because Alice gets to decide whether the trade happensor not. Therefore, to align incentives, the exchange’squote includes a spread around the current market price;this compensates the exchange for any volatility in mar-ket prices between the time the quote is given and thetime the trade is executed.

Arwen RFQs also include an way out for the exchange.In times of strife, when the exchange is unable to executea trade against a quote it provided, the exchange doeshave the option to abort a trade. The abort is possiblebecause Arwen’s off-blockchain RFQ trading instrumentis built from HTLC smart contracts similar to those ofTierNolan. Specifically, the exchange chooses a secretsolution x to a puzzle y = H(x), and releases x in orderto execute the trade. To abort the trade, the exchangerefuses to release x. The aborted trade, however, isungraceful and costly because it requires the user andexchange to stop trading and close the escrows backingthe aborted trade. While no coins are lost, this suf-ficiently harmful to the exchange’s reputation that wewould expect an exchange to avoid aborting wheneverpossible. A full protocol description is in Section 5.

Limit orders with Arwen. Arwen also supportsoff-blockchain fill-or-kill limit orders, where the user totells the exchange the lowest price at which she is willingto buy or sell coins. (i.e., Order: “I will sell 2 BTC ifI can buy at least 40 BCH”) A fill-or-kill order is onlyexecuted by the exchange if it can be completely filled(i.e., if all 40 BCH can be bought by the user). The user

4

also has the ability to cancel the order. This instrumentis well aligned with the exchange’s incentives, because itcan execute the limit order instantly, once market pricesalign with the user’s order. It also aligns with the user’sincentives, because she can essentially “name her price”and easily adjust her price based on market conditions(by cancelling the order).

2.7 White paper overview.The rest of this paper is organized as follows. In

Section 3, we start with an overview of Arwen thatcovers Arwen escrows, escrow fees, and the basics ofoff-blockchain trading. We then provide a detailed de-scription of Arwen’s unidirectional RFQ protocol for“Bitcoin-derived” blockchains, including those that donot support SegWit. Section 7 explains the reasonswhy this protocol withstands transaction malleabilityattacks on blockchains like BCH that lack SegWit sup-port. We describe how to port the unidirection RFQprotocol to Ethereum and ERC-20 tokens in Section 6.Arwen’s bidirectional RFQ protocol is in Section 8 andbidirectional limit order protocol is in Section 9. Wecompare Arwen to other atomic swap and layer-two pro-tocols in Section 10.

3. ARWEN OVERVIEWThe Arwen Trading Protocol is a blockchain-backed

two-party cryptographic protocol between a user Al-ice and a centralized cryptocurrency exchange. Alicefirst locks her coins in an on-blockchain user escrow.Next, Alice asks the exchange to lock its coins in anon-blockchain exchange escrow. To compensates the ex-change for locking up its coins, Alice pays and escrow feeto the exchange using the coins Alice locked in her userescrow. Alice can now trade across a pair of escrows.Each individual trade is an off-blockchain atomic swap,using one of the Arwen trading instruments described inSections 5. Finally, the escrows are closed and the coinsare released to the wallets of the user and the exchange.

3.1 The Arwen DaemonThe user executes the Arwen Trading Protocol using

the Arwen Daemon. The Arwen Daemon is an open-source executable that the user downloads to her localmachine. The Arwen Daemon allows the user to engagein the Arwen Trading Protocol without trusting a third-party or a webserver, thus realizing the promise of non-custodial cryptocurrency trading. The Arwen Daemonperforms the cryptographic operations involved in theArwen Trading Protocol, posts and verifies transactionsfrom relevant blockchains, and stores the secret tradingkeys used to securely trade against the Arwen escrows.

3.2 Opening on-blockchain escrows.Escrows are opened and closed by confirming a trans-

action on the coin’s native blockchain. (Thus, the trans-action that opens an escrow for bitcoins is confirmed onthe Bitcoin blockchain.) Opening and closing escrowstakes the same amount of time it would take to depositor withdraw coins from a custodial centralized exchange.

This exposition below assumes that Alice wishes to

trade her bitcoins for some litecoins, as shown Figure 1.

User escrow. Alice funds the on-blockchain user es-crow that is specific to this exchange. The user escrowlocks e.g., 5 BTC from the user’s wallet on the Bitcoinblockchain until some pre-agreed-upon expiry time twA.The initial balance in this escrow is 5 BTC owned by theuser, and 0 BTC owned by the exchange. While the es-crow is open, these coins are locked and cannot be usedfor anything other than cryptocurrency trades with theexchange. Once the escrow is closed, the balance of thecoins owned by the user are released and transferred tothe user’s wallet, and the balance of the coins ownedby the exchange are released and transferred to the ex-change’s wallet.

Exchange escrow. The exchange funds the exchangeescrow that is specific to this user Alice. To open theexchange escrow, Alice pays the exchange an escrow fee,as described in Section 3.5. The exchange escrow locks500 LTC from the exchange’s wallet on the Litecoinblockchain until some pre-agreed-upon expiry time tw .The locked coins cannot be used for anything other thancryptocurrency trades with this specific user. The ini-tial balance in this escrow is 0 LTC owned by the user,and 500 LTC owned by the exchange. Once the escrowis closed, the balance of the coins owned by the Aliceare released and transferred to Alice’s wallet, and thebalance of the coins owned by the exchange are releasedand transferred to the exchange’s wallet.

Pairing. Alice can execute multiple fast off-blockchaintrades against any (user escrow, exchange escrow) pair.If Alice has multiple open user escrows with a givenexchange, she can pair them with any of her open ex-change escrows with that exchange. In the example ofFigure 1, initially pairs her 5 BTC user escrow and her500 LTC exchange escrow, allowing her to sell up to 5BTC and buy up to 500 LTC.

Escrow expiry times. Escrows come with an expirytime that protect each party against a malicious coun-terparty. As long as the exchange is not compromised,the user can close her escrows early, before they expire.Escrow expiry times can vary, but must be longer thanthe time it takes to reliably confirm a transaction onblockchain. Thus, expiry times are least several hoursafter the escrow has been opened.

Escrow smart contracts. The Arwen escrow isa timelocked two-of-two multisig smart contract thatstipulates the following:

“coin may be released from escrow via a trans-action that is signed by both the user’s ephemeralkey and the exchange’s ephemeral key, ORafter time tw , the party that funded that es-crow can unilaterally withdraw coins fromthe escrow by signing a transaction usingtheir ephemeral key.”

Each ephemeral key is chosen and used for this specificescrow only. This way, even if a trading key is compro-mised, there is no risk to the coins that remain in theuser wallet or the exchange wallet. The user’s ephemeraltrading key is stored in the Arwen Daemon on the user’slocal machine.

5

Request: Sell 1 BTC for some LTC?

Quote: 1 BTC for 100 LTC.

Confirmed!

Order! 1 BTC for 100 LTC.

CENTRALIZED EXCHANGETRADER

First trade(off blockchain!)

User EscrowUser: 5 BTC Exchange: 0 BTC

Exchange EscrowUser: 0 LTC Exchange: 500 LTC

On-blockchain escrow

transactions

BTC CashOutUser: 2 BTC Exchange: 3 BTC

LTC CashOut:User: 300 LTC Exchange: 200 LTC

These transactions are posted to the

blockchain only when the escrows

are closed

Request: Sell 2 BTC for some LTC?

Quote: 2 BTC for 200 LTC.

Confirmed!

Order! 2 BTC for 200 LTC.Second trade

(off blockchain!)

Figure 1: Arwen Trading Protocol for a two RFQ trades between the user and exchange.

Bitcoin script implementation. When Arwen es-crows lock coins on blockchains that support the BitcoinScript language (e.g., BTC, BCH, LTC, ZEC, etc.), theArwen escrow smart contract operates is quite simple,comprising only 16 opcodes. (Bitcoin Script is a highlyrestricted language, reminiscent of Assembly language.)

User escrows and exchange escrows are transactionsconfirmed on their native blockchain. The reader mighttherefore wonder if a third party can inform their owntrading strategies by scanning the blockchain to find Ar-wen escrows. Fortunately, with Bitcoin-fork blockchains,a third party can only observe that a certain amountof coins has been transferred into a smart contract ad-dress; the amount of coins is visible on the blockchain,but the details of the smart contract are completely un-known to the third party. This follows because openingan escrow amounts to funding a P2SH-type address ona “Bitcoin-fork” blockchain. A P2SH address is just acryptographic hash of the smart contract itself. No de-tails of the smart contract are apparent from this hash,other than the fact that it is a smart contract. More-over, the P2SH-type address is commonly used by othersystems, not just by the Arwen Trading Protocol.

Ethereum smart contract implementation. TheEthereum and ERC-20 implementation of Arwen usesan escrow smart contract that mimics the UTXO trans-action paradigm that is used on Bitcoin. Once thesmart contract is funded, it enters the OPEN state,and remains in the OPEN state until either a trans-action is posted that is (1) doubly-signed by the users’sephemeral key and the exchange’s ephemeral key (thisis 2-of-2 multisig condition of the Arwen escrow), or (2)the escrow expires after time tw , and the party thatfunded the escrow posts a signed message that unlocksthe coins in the escrows (this is the timelock conditionof the Arwen escrow). See the description in Section 6.

3.3 Off-blockchain trading via atomic swaps.

Arwen supports several off-blockchain trading instru-ments, backed by the user escrow and exchange escrowscontracts. These trading instruments and their accom-panying cryptographic protocols are described in Sec-tions 5,6,9. Arwen trades are fast, because they hap-pen off-blockchain. To trade, the user’s Arwen Daemonand the exchange send cryptographic messages betweenthemselves. Because no other party can see these mes-sages, the trade is protected from front-running, grief-ing, and other strategic manipulations.

Each trade is an atomic swap, and cannot be reversedonce it executes. If a trade successfully executes, it re-sults in a pair of off-blockchain transactions that reflectthe balance of coins in the escrows after the trade. Thesetransactions protect the user and the exchange in casethe other party becomes uncooperative (i.e., maliciousor unresponsive), by allowing each party to unilaterallyclose the escrows without the help of the other party.

3.4 Closing on-blockchain escrows.Once an escrow is closed, the balance of coins owned

by the user is released into the user’s wallet, and the bal-ance of coins owned by exchange is released into the ex-change’s wallet. For instance, consider Figure 1, where(1) the user escrow was initially funded with 5 BTC,and (2) the exchange escrow was initially funded with500 LTC, (3) Alice performed two RFQ trades selling 3BTC in order to buy 300 LTC, and then (4) decided toclose both the user escrow and exchange escrow. Whenthe user escrow is closed, 2 BTC will be transferred intoAlice’s wallet, and 3 BTC will be transferred into theexchange’s wallet. When the exchange escrow closes,300 LTC will be transferred to the user’s wallet, and200 LTC will be transferred to the exchange’s wallet.

Cooperative close. In typical situations, whereneither the exchange nor the user is malicious or com-promised, then the user escrow and the exchange escrowcan be closed at any time, even before they expire. Each

6

escrow is closed via a cooperative exchange of messagesbetween the user and exchange. The output of this co-operation is a single cashout transaction, posted to theblockchain, that reflects the balance of the escrow andis doubly-signed by (1) the user’s trading key and (2)the exchange’s trade key.

Uncooperative close. The Arwen Trading Proto-col is secure atomic swap protocol because it allows theuser to unilaterally recover from the two unlikely situa-tions which may occur if the exchange is compromisedor unresponsive:

The exchange refuse to close an open escrow. In thiscase, the user can unilaterally close the escrow.

The exchange aborts a trade. An escrow is frozenwhenever an exchange improperly aborts a trade againstthat escrow. A frozen escrow cannot be used for trad-ing and must be closed. If the exchange refuses to co-operatively close a frozen escrow, Alice can unilaterallyrecover coins from the frozen escrow by connecting herArwen Daemon to the Internet during a specific coin-recovery time period. The Arwen Daemon notifies theuser about the coin recovery time period at the momentthe Arwen Daemon detects that the exchange improp-erly aborted a trade.

Similarly, Arwen allows the exchange to unilaterallyclose escrows when the user is malicious or unrespon-sive.These unilateral recovery procedures are the maintechnical contribution of the Arwen protocols, and arespecific to each of Arwen’s trading instruments. Seee.g., Sections 5.5,5.6,8.48.5 for the procedures used inArwen’s unidirectional RFQ trading protocol.

3.5 Arwen’s escrow fee mechanism.When an exchange funds an exchange escrow for a

specific user Alice (e.g., the 500 LTC exchange escrow inFigure 1), the exchange is locking coins in an escrow thatcan only be used by Alice. These coins can come out ofthe exchange’s own inventory. Alternatively, they couldbe coins deposited by custodial users that the exchangeuses to fund escrows, in exchange for earning intereston those deposits.

For this reason, when Alice requests an exchange es-crow, she first pays an escrow fee to compensate theexchange for locking up its funds. Arwen’s escrow feesare an in-band mechanism that avoids the introductionof out-of-band payments or of a superfluous fee token.

The escrow fee mechanism. The escrow fee is pro-portional to the amount of coin locked in the exchangeescrow, and to the expiry time of the exchange escrow.Alice pays the escrow fee upfront, before she opens theexchange escrow. Alice receives a rebate of a portion ofthe escrow fee if she closes the exchange escrow early,before it expires.

Alice pays the upfront escrow fee via a fast off-blockchaintransfer out of the coins locked in one of her user es-crows. Alice receives the rebate out of the exchangeescrow, once that exchange escrow is closed.

Paying escrow fees. This is best illustrated with anexample. Consider the situation in Figure 1, and sup-pose that Alice has an open user escrow with a balance

of 5 BTC owned by Alice. Alice then asks the exchangeto open a 500 LTC exchange escrow for her that ex-pires two days later, and indicates that she can pay theescrow fee out of her BTC user escrow.

Suppose the escrow fee for the requested exchangeescrow is 1 LTC/day and Alice decides to pay the up-front escrow fee using her BTC user escrow. First, theexchange performs a currency conversion of the escrowfee, converting it from 2 LTC into 0.02 BTC. Next, theexchange quotes an escrow fee of 0.02 BTC to Alice. IfAlice accepts this fee, Alice sends the exchange a 0.02BTC off-blockchain payment from her user escrow thatalters the balance in the user escrow so that the ex-change owns 0.02 additional BTC and Alice owns 4.98BTC. Once the exchange receives this payment, the ex-change funds an exchange escrow for Alice for 500 LTC.

Escrow fee rebate. Now suppose that Alice hasmade trades that alter the balance in the exchange es-crow so that 300 LTC is owned by Alice and 200 LTC isowned by the exchange. Alice then decides to closes herexchange escrow one day early, so she is entitled to aescrow-fee rebate of 1 LTC. Alice is paid the rebate outof the closed exchange escrow. Thus, the exchange es-crow is closed with a balance of 301 LTC sent to Alice’swallet and 199 LTC sent to the exchange’s wallet.

4. SECURITY MODEL.Arwen assumes that the exchange is almost always on-

line, while the user is usually not online. Atomic swapsecurity for users of Arwen follows from five assump-tions.

1. The traded coins’ native blockchain is secure. Thatis, when trading bitcoins we assume that the Bit-coin blockchain is secure.

2. The user’s Arwen Daemon has not been compro-mised. (Note that the Arwen Daemon is open-source and therefore can be audited.)

3. The user correctly deposits coins in her user es-crow. (This is exact same assumption on user be-havior that is made whenever a user deposits coinsat a cryptocurrency exchange.)

4. The user correctly informs the Arwen Daemon ofthe wallet addresses where she wants her coinstransferred to upon closing each escrow. (Thisis exact same assumption on user behavior thatis made whenever a user withdraws coins from acryptocurrency exchange.)

5. The user remembers to come online in order to re-cover coins from frozen escrows during their coin-recovery time period, and to close escrows in a“timely manner”. Each Arwen protocol has a spe-cific definition of what it means to close escrowsin “timely manner”. (The users coins are at riskonly if the exchange is compromised or malicious,and the user forgets to close escrows in a timelymanner or to recover coins from frozen escrows.)

7

These assumptions only related to the blockchain (as-sumption 1), the user’s computing environment (assump-tion 2) and the user’s behavior (assumption 3-5). Secu-rity for the user makes no assumptions about the se-curity or correctness of the cryptocurrency exchange orany other party.

Atomic-swap security for the exchange analogouslyfollows from five analogous assumptions, and analogouslymakes no assumptions about the security or correctnessof the user or any other party.

5. UNIDIRECTIONAL RFQSThe following protocol is unidirectional [32] because

it only allows Alice to sell coins from her user escrow,and buy coins from her exchange escrow. Arwen’s morecomplex bidirectional RFQ protocol is described in Sec-tion 8. This unidirectional protocol is for“Bitcoin-derived”blockchains, including those without SegWit, and thuswithstands transaction malleability attacks for the rea-sons explained in Section 7. Section 6 explains how toport this protocol to Ethereum and ERC-20 tokens.

Each off-blockchain RFQ trade is backed by a userescrow (with expiry time twA) and an exchange escrow(with expiry time twB). The protocol for opening theseescrows is in Section 3.2. Both escrows must be openduring a trade (rather than expired, frozen, or closed).

Each new trade generates a pair of timelocked puz-zle transactions for puzzle y, along with correspond-ing solution x where x is chosen by the exchange andy = H(x). One puzzle transaction spends the outputof the user escrow and has timelock τA, and the otherspends the output of the exchange escrow and has time-lock τB. Each pair of puzzle transactions reflect thenew balance of coins in the escrows after the trade, and“overwrites” the pair of transactions generated by theprevious trade. The puzzle transactions and solution xand allow each party to unilaterally close escrows withthe correct balance of coins, even if the other party be-comes malicious.

5.1 Security assumptions.Timelocks. The security of this protocol follows be-cause we set the timelocks to be

τA = twA τB = max(twB, τA + 2%) (1)

where % is the time required for transaction be reliablyconfirmed on the blockchain. Importantly, notice thatthere is no relationship between the escrow expiry times(twA, twB), which means we can pair any user escrowand exchange escrow, regardless of their expiry time.

Closing escrows in a timely manner. To with-stand attacks by a compromised or malicious exchange:

The user must close her exchange escrow be-fore it expires at time twB.

If the user forgets to do this, an honest exchange willclose the escrow on the user’s behalf, but a maliciousexchange may be able to steal coins from the escrow.This requirement is for exchange escrows only; there isno requirement that the user close her user escrows in

a timely manner. Similarly, to withstand attacks by acompromised or malicious user:

The exchange must close its user escrow be-fore it expires at time twA.

Finally, the time period in which the user can unilater-ally recover coins from frozen escrows is (twA, τB).

5.2 Off-blockchain RFQ trades.This exposition below follows Figure 1. We suppose

that the user Alice wants to do a trade, selling 2 bitcoinsfor 200 litecoins. We also assume that, in all previoussuccessfully-completed trades, Alice has sold at total 1BTC from the user escrow and 100 LTC from the ex-change escrow that are backing the current trade. EachRFQ is an off-blockchain four-message protocol com-prising the following four messages.

Request. Alice requests a quote to sell 2 BTC inorder to buy LTC.

Quote. The exchange responds with the quote—“2BTC can be sold for 200 LTC, open for time δ”. Theexchange has now committed to executing the trade,should Alice choose to place an order before the quoteexpires at time δ. To align incentives, the quote reflectsthe current market price at the exchange, plus an addi-tional spread that compensates the exchange for pricefluctuations between the moment the quote is provided,and the moment the trade is executed.

To commit to the quote, the exchange chooses a se-cret solution x and computes a puzzle y = H(x). Theexchange sends Alice the following Litecoin puzzle trans-action for the Litecoin blockchain. The puzzle transac-tion (1) is signed by the exchange’s ephemeral key, (2)spends the output of the exchange escrow, and (3) re-flects the current balance in the LTC exchange escrow,except that 200 LTC is locked in an HTLC smart con-tract stipulating that

”The coins may only be unlocked via a trans-action that contains the solution to puzzle yand is signed by the user’s ephemeral key,ORafter time τB, the exchange can unilaterallyunlock coins from the escrow by signing atransaction using its ephemeral key.”

In other words, the puzzle transaction sends 100 LTCto Alice’s wallet, locks 200 LTC in an HTLC smart con-tract under puzzle y, and sends the remaining 200 LTCto the exchange.

(Notice that Alice could sign this puzzle transactionand post it to the Litecoin blockchain. This would re-lease all coins locked in the user escrow, except those 200LTC locked under the puzzle y. However, Alice does notsign or post anything to the Litecoin blockchain untilshe is ready to close her exchange escrow.)

Order. If the user decides not to place the order,then the escrows remain open and can be used for othertrades. (This follows because only the exchange knowsthe secret solution x. Without x, the Litecoin puzzletransaction is useless to Alice. Nevertheless, if Alice

8

does decide to post the puzzle solution to the Lite-coin blockchain, the exchange can reclaim the 200 LTClocked under the puzzle after its timelock expires at τB.)

To place an order, Alice signs and sends the exchangea new Bitcoin puzzle transaction using the same puzzley chosen by the exchange. The puzzle transaction (1) issigned by Alice’s ephemeral trading key, (2) spends theoutput of the user escrow, and (3) reflects the currentbalance in the user escrow, except that 2 BTC is lockedin an HTLC smart contract stipulating that

”The coins may only be withdrawn via atransaction that contains the solution to puz-zle y and is signed by the exchange’s ephemeralkey, ORafter time τA, the user can unilaterally with-draw coins from the escrow by signing a trans-action using its ephemeral key.”

At this point in the protocol, Alice cannot abort theorder, because the exchange can now unilaterally decidewhether or not the trade executes. (This follows becausethe exchange can use this puzzle transaction, and thesolution x to unilaterally close the user escrow as if thistrade was executed.)

Execute. If the user placed the order before timeδ, then the exchange is expected to execute the tradeby sending the solution x to the user. This executesthe atomic swap, because now both the user and theexchange hold transactions that allow them to unilater-ally close their escrows, reflecting the new balance afterthe trade. (Specifically, the user can unilaterally closethe exchange escrow, and the exchange can unilaterallyclose the user escrow.) However, in most situations theuser will prefer to keep trading against her open es-crows. In this case, no transactions are posted to theblockchain, and the user escrow and the exchange es-crows remain open.

What if the exchange does not properly execute thetrade by releasing x? In this case, Alice will freezethe user escrow and exchange escrow that backed theaborted trade and launch a procedure for recovering hercoins, as described in Section 5.6.

5.3 The magic of unidirectionality.The security of our protocol follows, in part, from

an observation first made by Spilman [32]. This is aunidirectional protocol, which means that the user canonly use the exchange escrow to buy coins from the ex-change. Thus, each subsequent trade changes the bal-ance of coins in the exchange escrow such that the userholds more litecoins and the exchange holds less lite-coins. For this reason, the user will always prefer to postthe transactions resulting from the most recent trade tothe Litecoin blockchain. This is why the Litecoin trans-actions resulting from a new trade will “overwrite” theLitecoin transactions resulting from the previous trade.

In other words, the user is incentivized to close theexchange escrow before it expires using the transactionsresulting from the most recent trade. If the user goesrogue and closes the exchange escrow using transactionsfrom a prior trade, she only hurts herself (because she

will have fewer coins), not the exchange (because theexchange will have more coins)!

Similar reasoning explains why the exchange prefersto close the user escrow before it expires using the trans-actions from the most recent trade.

Paying escrow fees. The magic of unidirectionalityalso makes it easy for the Alice to pay escrow fees out ofher user escrow. Suppose that, after the second trade inFigure 1, Alice wishes to pay an 0.02 BTC escrow fee inorder to open a new exchange escrow. To do this, Alicesigns and sends the exchange a cashout transaction thatreflects the current balance of the user escrow, with anadditional 0.02 BTC allocated to the exchange. Specif-ically, the cashout transaction (1) spends the output ofthe user escrow, (2) sends 3.02 BTC to the exchange’swallet, and 1.98 BTC to the user’s wallet. The sameunidirectional argument means that the exchange is in-centivized to have this cashout transaction “overwrite”the puzzle transaction received from the previous trade.This cashout transaction could then be signed by theexchange and posted to the blockchain if the exchangeneeds to unilaterally close the user escrow.

5.4 Closing escrows.Cooperative close. If neither the user nor the ex-change is unresponsive or malicious, escrows are closedprior to their expiry using the cooperative close proce-dure outlined in Section 3.4. Specifically, the user sendsthe exchange a signed cashout transaction reflecting thefinal balance in the escrow. The exchange then signsthat transaction and posts it to the blockchain. For ex-ample, to cooperatively close the user escrow after thetrade described above, the cashout transaction would(1) spend the output of the user escrow, (2) send 3 BTCto the exchange’s wallet, and 2 BTC to the user’s wallet,and (3) be signed by both the user and the exchange.

Incentives for a cooperative close. Coopera-tively closing an escrow is in the interest of both parties,because it allows them to reduce mining fees by clos-ing their escrows using a one transaction, rather thantwo (i.e., the puzzle transaction and a solve transac-tion that contain the solution x to puzzle y). Moreover,because the puzzle transaction is generated in advance,it must include a highly conservative blockchain min-ing fee. This is necessary to cope with unpredictablefluctuations in mining fees between the time the puz-zle transaction was created during the RFQ trade, andthe time it might get posted to the blockchain to uni-laterally close the escrow. A cooperative close of theexchange escrow also allows the user to earn a rebateon her escrow fees, as described in Section 3.5.

Unilateral close. However, if one of the partiesrefuses (or forgets) to engage in a cooperative close, ourprotocol ensures that their counterparty can unilater-ally close the escrows and obtain at least those coinsthey rightfully hold according to the final balance inthe escrow. (In fact, there are cases where a unilat-eral close allows the counterparty to obtain additionalcoins beyond those coins that they rightfully hold ac-cording to the final balance in the escrow.) Each party’sprocedure for closing an open escrows when the coun-

9

user escrow

5 BTC

puzzle transaction y

2 BTC 1 BTC 2 BTC

solvex where y = H(x)

2 BTC

puzzle refund

2 BTC

cashout

2 BTC 3 BTC

Uwallet

Ewallet

(Etrade Ʌ Utrade) or (Urefund Ʌ twA)

(x Ʌ Epuzz) or (Urefund Ʌ τA)

Uwallet Ewallet

Utrade Etrade

Epuzz

Uwallet

Urefund

Utrade Etrade

Ewallet

refund

2 BTC 3 BTCUwallet Ewallet

Urefund

Uwallet

Figure 2: Diagram of transactions pointing to the user escrow for the unidirectional RFQ protocolof Section 5. Per Figure 1, we suppose that the user has already received 1 BTC and is engagingin a trade for an additional 2 BTC. Transactions in color are only posted to the blockchain if aparty becomes uncooperative. The ⊕ symbol is an XOR: only one of the transactions from the ⊕can be posted to the blockchain. The lock symbol represents a signature. The transactions shownin green and blue are posted by the exchange to unilaterally close the escrow if the user becomesuncooperative, or forgets to close the escrow before time twA. The transaction in purple is used bythe user to unilaterally close the user escrow after it expires at time twA; here we depict the casewhere all trades properly complete but the exchange did not cooperate to close the escrow, so theuser benevolently transfers 2 BTC to the exchange’s wallet, rather than “stealing” these BTC forherself. The transaction in magenta is used by the user to unilaterally release coins locked in puzzletransaction, after the puzzle expiry time of τA; this transaction is only used when the exchange postsa puzzle transaction but fails to post the corresponding solve transaction.

exchange escrow

500 LTC

puzzle transaction y

200 LTC 100 LTC 200 LTC

solvex where y = H(x)

200 LTC

puzzle refund

200 LTC

cashout

200 LTC 300 LTC

Ewallet

Uwallet

(Etrade Ʌ Utrade) or (Erefund Ʌ twB)

(x Ʌ Upuzz) or (Urefund Ʌ τB)

Ewallet Uwallet

Etrade Utrade

Upuzz

Ewallet

Erefund

Etrade Utrade

Uwallet

Ewallet

refund

200 LTC 300 LTCEwallet Uwallet

Erefund

Figure 3: Diagram of transactions pointing to the exchange escrow for the unidirectional RFQ protocolof Section 5. Per Figure 1, we suppose that the user has already received 100 LTC and is engagingin a trade for an additional 200 LTC. Transactions in color are only posted to the blockchain if aparty becomes uncooperative. The transactions shown in green and blue are posted by the user tounilaterally close the escrow if the exchange becomes uncooperative. The transaction in purple isused by the exchange to unilaterally close the exchange escrow after it expires at time twB; here wedepict the case where all trades properly complete but the user forgets to close the exchange escrowbefore it expired, so the exchange benevolently transfers 200 LTC to the user’s wallet, rather than“stealing” these LTC for itself. The transaction in magenta is used by the exchange to unilaterallyrelease coins locked in puzzle transaction, after the puzzle expiry time of τB; this transaction is onlyused when the user posts a puzzle transaction but fails to post the corresponding solve transaction.

10

terparty is malicious or uncooperative is in Section 5.5.The user’s procedure for recovering coins from a frozenescrow is in Section 5.6.)

5.5 Unilaterally closing an open escrowWhat happens if the user and exchange fail to co-

operatively close an escrow before it expires? Here weconsider only the case where the escrow is open, i.e.,where all trades against that escrow have properly com-pleted. Recovery from an escrow that is frozen due toan aborted trade is described in Section 5.6. There arefour relevant cases.

5.5.1 Exchange refuses to close exchange escrow.In this case, Alice’s Arwen Daemon can unilaterally

close the exchange escrow before it expires at time twB,by signing and posting the puzzle transaction and thensigning and posting the solve transaction that resultedfrom the latest trade. (See Figure 3.) This releases coinsto Alice’s wallet and the exchange’s wallet, according tothe balance in the escrow after the last completed trade.

Alice’s coins are safe if she closes the exchangeescrow before time twB. This follows because onlyAlice can close the exchange escrow before twB, whichprotects her from race conditions with a malicious ex-change or any other party. To see why, recall fromSection 3.2 that, to close the exchange escrow beforeit expires, we require a transaction doubly-signed byboth the user and the exchange. The RFQ protocolabove ensures that only Alice has such a transaction—the Quote message provides the user with a puzzle trans-action, signed by the exchange, that spends the outputof the exchange escrow. Alice can unilaterally sign thispuzzle transaction to create the required doubly-signedtransaction, and unilaterally post this transaction to theLitecoin blockchain. Meanwhile, the exchange does notthe ability to create such a doubly-signed transaction,because Alice never sends the exchange a signed trans-action that spends the output of the exchange escrow.

Once the puzzle transaction is confirmed by the blockchain,Alice can use the corresponding solution x to sign andpost a solve transaction to he blockchain, releasing thecoins locked in the HTLC smart contract in the puzzletransaction to Alice’s wallet. Also, Alice is protectedfrom race conditions because only Alice can spend thecoins locked in the HTLC before twB. This follows be-cause equation (1) is such that the HTLC’s timelock τBexpires after time twB .

5.5.2 User forgets to close exchange escrow.What happens if Alice forgets to close her exchange

escrow before it expires? Alice’s coins are at risk onlyif the exchange becomes malicious.

This follows because an exchange can unilaterally closean exchange escrow after it expires at time twB using arefund transaction (see Figure 3). The refund transac-tion (1) is signed by the exchange, and (2) spends theoutput of the exchange escrows. An honest exchangewill (3) form the refund transaction so that it releasescoins to Alice’s wallet and the exchange’s wallet accord-ing to the final balance of in the escrow. However, a

malicious exchange could instead have the refund trans-action release all coins to the exchange’s wallet; this iswhy we say the user’s coin are risk if she forgets to closeher exchange escrow before it expires.

Meanwhile, an malicious user Alice cannot steal theexchange’s coin even if the exchange decides to close theexchange escrow significantly after time twB. This fol-lows because even if Alice decides to race the exchange’srefund transaction, Alice can only attempt to close theescrow with a puzzle transaction that either (1) reflectsthe final balance of in the escrow (i.e., at the same bal-ance at which the honest exchange is attempting to closethe user escrow) OR (2) reflects the balance of in theescrow after any earlier completed trade (i.e., a balancewhere the exchange holds more coins than it does in thefinal balance of the escrow, which is worse for Alice andbetter for the exchange!)

5.5.3 User forgets to close user escrow.Suppose the user forgets to cooperatively close a user

escrow before it expires at time twA. Here, the ex-change must unilaterally close the user escrow beforetime twA. To do this, the exchange signs and posts thepuzzle transaction, and then signs and posts the solvetransaction, both of which resulted from the latest com-pleted trade (see Figure 2). (If the final off-blockchaintransfer against this escrow was due to Alice paying anescrow fee, then the exchange would instead close theescrow using the cashout transaction used to pay theescrow fee; see Section 5.3.) This releases coins to Al-ice’s wallet and the exchange’s wallet, according to thefinal balance in the escrow. The exchange must do thisbefore time twA in order to avoid race conditions witha malicious Alice. This follows from reasons analogousto those given in Section 5.5.1.

5.5.4 Exchange refuses to close user escrow.If the exchange refuses to cooperatively close a user

escrow, the user’s coins are not at risk. The user justneeds to wait until the user escrow expires, at whichpoint her Arwen Daemon will automatically and unilat-erally close the user escrow using a refund transaction(see Figure 2). This follows because the user escrowsmart contract allows the user to unilaterally unlock thecoins in the user escrow after time twA. Alice is in norush to unilaterally close this user escrow—her ArwenDaemon can do this at any time after the user escrowexpires at time twA. This follows for reasons analogousto those in Section 5.5.2.

5.6 Recovering coins from frozen escrows.Suppose that during the last trade, the user placed

an order against a quote provided by the exchange, butthe exchange failed to properly execute the order byreleasing the preimage x. This is an unlikely case, be-cause the exchange is supposed to execute any ordersplaced against any of its quotes. This last trade is con-sidered to be improperly aborted. Whenever the ArwenDaemon detects an improperly aborted trade, it pro-tects the user’s coins by freezing the user escrow andexchange escrow that backed this trade. Frozen escrowscannot be used for trading.

11

Next, the user’s Arwen Daemon immediately asks theexchange to cooperatively close the user escrow (on theBitcoin blockchain) and exchange escrow (on the Lite-coin blockchain) that backed this trade, under the as-sumption that the balance in these escrows is as it wasprior to the final, improperly-aborted trade. If the ex-change agrees to close both escrows, then no furtheraction is required from the user.

However, suppose that the exchange refuses to closethe frozen exchange escrow. In this case, the user’s Ar-wen Daemon will immediately and unilaterally close theexchange escrow by posting the puzzle transaction fromthe aborted trade. Doing this, however, means that thecoins in the exchange escrow, that were involved theaborted trade, are still locked in the puzzle transaction’sHTLC smart contract until time τB. We call these coinsthe outstanding coins. The outstanding coins rightfullybelong to Alice if the exchange sneakily executed theaborted trade on the Bitcoin blockchain without tellingAlice; otherwise, the outstanding coins rightfully belongto the exchange. The remainder of this procedure is al-lows Alice to claim the outstanding coins whenever theyare rightfully hers.

What happens next depends on whether the exchangealso agreed to cooperatively close the user escrow. If so,no further action is required from Alice. This followsbecause the user escrow was closed according to thebalance before to the aborted trade, so the outstandingcoins rightfully belong to the exchange. The exchangecan unilaterally claim the outstanding coins once thetimelock τB expires by posting a puzzle-refund transac-tion, signed by the exchange, that sends the outstandingcoins to the exchange’s wallet.

Otherwise, the exchange refused to cooperatively closethe user escrow. Alice must come online during timewindow (twA, τB) to allow her Arwen Daemon to claimthe outstanding coins. Thus, the Arwen Daemon scansthe Bitcoin blockchain looking for transactions that spendthe user escrow. There are several cases:

• User escrow closed using a successful trade. Theexchange closed the user escrow on the Bitcoinblockchain via a puzzle transaction for any tradeprior to the aborted trade. No further action isneeded from the Arwen Daemon. This follows be-cause the outstanding coins rightfully belong tothe exchange, and the exchange can unilaterallyclaim them once the timelock τB expires via apuzzle-refund transaction.

• User escrow closed using the aborted trade. Theexchange closed the user escrow on the Bitcoinblockchain via a puzzle transaction for the abortedtrade, as well as its corresponding solve transac-tion. The Arwen Daemon learns the solution xfrom solve transaction on the Bitcoin blockchain.The Arwen Daemon then uses x to form and signthe solve transaction for the Litecoin blockchain,claiming the outstanding coins for Alice. Impor-tantly, the Arwen Daemon must complete this ac-tion before τB, because the outstanding coins canbe unilaterally claimed by the exchange after τB,which puts Alice’s coins at risk.

• User escrow partially closed. The exchange postedthe puzzle transaction for any trade made againstthis user escrow, but the coin locked in this puzzletransaction on the Bitcoin blockchain are unspent.In this weird case, the exchange has not executedthe aborted trade without telling the user, and sothe user will not be able to claim the outstandingcoins on the Litecoin blockchain. Nevertheless, theArwen Daemon must still recover the coins lockedin the puzzle output from the user escrow on theBitcoin blockchain and send them back to the Al-ice’s wallet. The user can unilaterally do this afterthe timelock on puzzle transaction expires at timeτA, by posting a puzzle-refund transaction to theBitcoin blockchain that sends locked coinsback toAlice’s wallet. Note that τA = twA for all tradesmade against this user escrow, which means thatArwen Daemon can take this action during thetime window (twA, τB).

• User escrow not closed. Here the output of theuser escrow is unspent. This again means that ex-change has not executed the aborted trade, so theuser cannot claim the outstanding coins. How-ever, the Arwen Daemon must still recover thecoins locked in the user escrow. The Arwen Dae-mon will post the refund transaction that releasescoins to Alice’s wallet and the exchange’s wallet,according to the balance in the escrow prior tothe aborted trade. The can be done anytime af-ter time twA when the user escrow expires, whichmeans that Arwen Daemon can take this actionduring the time window (twA, τB).

Once this process is complete, both the user escrow andthe exchange escrow are closed.

6. ETHEREUM UNIDIRECTIONAL RFQSWe now describe how to port the unidirectional RFQ

protocol of Section 5 to Ethereum and ERC-20 tokens [36].We use an escrow smart contract that mimics the UTXOtransaction paradigm that is used on Bitcoin.

Ethereum Smart contract. Each user escrow andexchange escrow is a smart contract that can be in oneof three states: (OPEN, PUZZLE, CLOSED). Coins arelocked when the escrow is OPEN, and released when theescrow is CLOSED. The PUZZLE state is for trading.

The user escrow can move from the OPEN state tothe CLOSED state via a:

1. refund transaction which is signed by the user andposted to the blockchain after time twA, (thus ful-filling the timelock condition of the Arwen escrow)

2. cashout transaction which is doubly-signed by theuser and by the exchange, (thus fulfilling the 2-of-2multisig condition of the Arwen escrow)

Meanwhile, the escrow smart contract moves from theOPEN state to the PUZZLE state when a puzzle trans-action, that calls a method in the escrow smart contract,is confirmed on the Ethereum blockchain. The puzzletransaction is doubly-signed by the user’s ephemeral key

12

and the exchange’s ephemeral key (thus fulfilling the 2-of-2 multisig condition of the Arwen escrow) and con-tains a puzzle y and an puzzle timelock τ (which areused for atomic swap trading). Then, a user escrow canmove from the PUZZLE state to the CLOSED state via:

3. solve transaction which contains solution x and issigned by the exchange

4. puzzle-refund transaction which is signed by theuser and posted to the blockchain after time τA

The exchange escrow can be analogously arrive in theCLOSED state in four ways (i.e., via solve, puzzle-refund, refund, or cashout transaction).

The RFQ protocol is essentially identical to that ofSection 5. The four ways that the user escrow can beclosed are identical to the four ways that an escrow canbe closed in the protocol of Section 5 (see also Figure 2).As in Section 5, the cashout transaction is used for co-operatively closing an escrow, while the puzzle, solve,refund, and puzzle-refund transactions are used to uni-laterally close escrows per Section 5.5, 5.6.

ERC-20 smart contract. Our ERC-20 implemen-tation of Arwen is identical to the Ethereum implemen-tation, with the following key modification.

The ERC-20 implementation of the Arwen escrowsmart contract includes an additional state, UNFUNDED,which is used to lock ERC-20 tokens in Arwen escrows.(Recall that an ERC-20 token is created via the im-plementation of a single standard ERC-20 smart con-tract on the Ethereum blockchain, where the state ofthe ERC-20 contract tracks the number of tokens heldby each account holder of the token. Thus, the Arwenescrow smart contract must alter the state of the ERC-20 smart contract in order to lock coins in escrow.)

To see how this is done, we describe the three-stepprocess used by Alice to lock 5 tokens in a user es-crow. First, Alice posts the user escrow smart contractto the Ethereum blockchain; at this point, the escrowis in the UNFUNDED state. Second, Alice call the ap-prove method in the token’s ERC-20 smart contract, in-dicating that she approves the transfer of 5 tokens fromAlice’s address to the user-escrow smart contract’s ad-dress. Third, Alice calls the fund-escrows method inthe user escrow smart contract, which interacts withthe ERC-20 smart contract to transfer the required 5token into the user escrow smart contract. Similarly,when the user escrow is CLOSED, it interacts with theERC-20 smart contract to release the balance of tokensfrom the user-escrow smart contract address into bothAlice’s address and the exchange’s address.

7. TRANSACTION MALLEABILITYArwen withstands transaction malleability attacks on

“Bitcoin-derived‘’ blockchain that do not have SegWit.We now explain the transaction malleability problem,discuss why it affects layer-two blockchain protocols,and explain how Arwen avoids it. Withstanding trans-action malleability allows Arwen to support more Bitcoin-derived blockchains.

Transaction malleability. Consider a transac-tion T2 that spends the output of a transaction T1. T2

therefore contains a pointer to T1, called the TXID.This TXID is malleable: the TXID can be changed(“mauled”) by anyone, without affecting the validity orcontents of transaction T1.

We explain why as follows. The TXID on T1 is thehash of (essentially) the entire T1, including any sig-natures on T1. Most “Bitcoin derived” blockchains useelliptic curve digital signatures, which are not determin-istic. (That is, a random value r is used to compute thesignature σ on message m.) This means that a partythat holds the secret signing key can easily produce mul-tiple valid signatures σ, σ′, . . . on a single message m.Worse yet, even a party that does not know the secretsigning key can take a valid signature σ on a messagem, and maul σ to obtain a different valid signature σ′

on m. Now, because TXID is the hash of (essentially)the entire T1, mauling the signatures on T1 results in acompletely different TXID for T1. Additionally, someparts of the transaction that are included in the TXIDhash are not covered by the signature on the transac-tion, which creates an additional malleability problem.

SegWit. With SegWit [39], the TXID hash is notcomputed over the signatures on the transaction. Thissolves the malleability problem, because now maulingthe signature has no effect on the TXID. SegWit also re-moves other malleability vectors (i.e., parts of the trans-action that are not covered by the signature).

Impact on layer-two protocols. If T1 is alreadyreliably confirmed on the blockchain, the security of theblockchain ensures that no one call maul the signatureson T1, and transaction malleability is irrelevant.

Now consider a layer-two protocol where Alice holdsT1, an off-blockchain transaction that spends an on-blockchain transaction T0. Next suppose that Alicetransfers coins to Bob by sending Bob an off-blockchaintransaction T2 that is signed by Alice and contains apointer to T1. Transaction malleability means that Al-ice’s signature on T2 is completely useless. This fol-lows because Alice can break the TXID pointing fromT2 to T1 by mauling the signatures on T1; this meansthat T2 becomes an invalid transaction but T1 remainsvalid. Thus, Bob could not use T2 to claim coins fromT0. (This is exact reason why the Lightning Network,as currently designed, only works with blockchains thatsupport SegWit, see Appendix A of [25].)

How Arwen avoids this problem. To avoid thisproblem, Arwen ensures that parties never need to sendeach other signatures on off-blockchain transactions thatpoint to other off-blockchain transactions. Instead, par-ties only send each other signatures on off-blockchaintransactions that point directly to the Arwen on-blockchainescrows. This further implies that if an off-blockchaintransaction comes with a smart contract (e.g., like theHTLC smart contract on the off-blockchain puzzle trans-action), then each clause on that smart contract mustrequire the signature of only one party. If a singleclause required the signature of more than one party,then parties would need to send each other signatureson off-blockchain transactions that point to other off-blockchain transactions, which is vulnerable to transac-tion malleability. The reader is invited to check that

13

Arwen is robust to transaction malleability, by checkingthat each clause on a smart-contract in an off-blockchaintransaction only requires the signature of a single party;see Figures 2,3,4.

This is also why we can not use relative timelocks i.e.,CheckSequenceVerify [9] in Arwen. CheckSequenceVer-ify (which is used extensively in Lightning) provides atimelock which is relative to the time another transac-tion is confirmed on-blockchain. CheckSequenceVerifyis therefore not safe to use on blockchains vulnerableto transaction malleability attacks, like BCH or ZEC.Instead, Arwen can only use absolute timelocks i.e.,CheckTimeLockVerify [35].

8. BIDIRECTIONAL RFQSThe following Arwen RFQ protocol is bidirectional,

because it allows Alice to both buy and sell coins fromher user escrow, and to both buy and sell coins fromher exchange escrow. A bidirectional protocol is usefulfor high-frequency trading strategies, where the traderquickly moves coins back and forth.

Like the unidirectional protocol of Section 5, each off-blockchain RFQ trade in the bidirectional protocol isbacked by a user escrow (with expiry time twA) and anexchange escrow (with expiry time twB). The protocolfor opening these escrows remains identical to the onein Section 3.2. Both escrows must be open during atrade (rather than expired, frozen, or closed). In whatfollows, we first overview the technical tools used in ourbidirectional protocol, describe the off-blockchain trad-ing protocol, and explain how escrows can be securelyclosed when one party becomes malicious or uncooper-ative. The transaction diagram for the user escrow andexchange escrow is in Figure 4.

8.1 Technical toolsWe continue to execute trades using HTLCs, where a

trade is executed by revealing the solution x to a puzzley, where y = H(x). However, but there are several othertechnical tools needed in order to make this protocolbidirectional. We outline some tools below.

Four puzzles transactions. In the unidirectionalprotocol, there was only a single type of puzzle transac-tion that could spend the output of each escrow. In thebidirectional protocol, there are four puzzle transactionsper escrow: payU postU, payU postE, payE postU, andpayE postE. This is true for both the user escrow andthe exchange escrow. The only difference between thepuzzles for the user escrow puzzles and the puzzles forthe exchange escrow is that user escrow puzzles havetw = twA and exchange escrow puzzles have tw = twB.The user will only post a puzzle transaction if the ex-change aborts a trade. The exchange will post a puzzletransaction if the user aborts a trade or if the user failsto cooperatively close an escrow before it expires.

payE and payU puzzles. By having both payE andpayU puzzles for each escrow, each escrow can be usedto both buy and sell coins. In a payE puzzle, the puzzlelocks coins that pay to the exchange once the exchangereveals x in a solve transaction, before time τA. ThepayE puzzle transaction has an HTLC smart contract

that is similar to the one in Figure 2 of our unidirectionalprotocol, using timelock τA and puzzle y. In a payUpuzzle, the puzzle locks coins that pay to the user, oncethe user reveals x in a solve transaction before timeτB . The payU puzzle has an HTLC smart contract thatis similar to the one in Figure 3 of our unidirectionalprotocol using timelock τB and puzzle y.

If the user is doing a trade that buys coins from theuser escrow while selling coins from the exchange es-crow, we would use a payU puzzle that spends the userescrow and a payE puzzle that spends the exchange es-crow. Meanwhile, to buy coins from the exchange es-crow while selling coins from the user escrow, we usea payE puzzle that spends the user escrow, and payUpuzzle that spends the exchange escrow.

postU and postE puzzles. A postU puzzle transactioncan only be posted to the blockchain by the user. ThepostU puzzle transaction is initially formed and signedby the exchange, and then sent to user; the user canlater post this transaction to the blockchain if the ex-change becomes uncooperative. The analogous postEpuzzle transaction can only posted by the exchange

Two cashout transactions. The postU cashout issigned by the exchange and sent to the user, and is usedto unilaterally close an escrow when all trades againstthe escrow completed successfully. The postE cashout,which is signed by the user and sent to the exchange, isused to cancel RFQ quotes.

Cancelling transactions. Arwen’s bidirectionalRFQ protocol no longer relies on “the magic of unidirec-tionality” (Section 5.3). Instead, we “overwrite” trans-actions resulting from old trades by cancelling them,adapting the idea of justice transactions from the Light-ning Network [29].

Every postE-type transaction, which is first signed bythe user and then sent to the exchange, can be cancelledby the exchange using the cancel value CE . The cancelvalue CE is randomly chosen and kept secret by the ex-change. To cancel the postE transaction, the exchangereveals CE to the user. The cancel value CE protects theuser if the exchange posts a canceled postE transactionto the blockchain, as follows. The postE transactioncontains a value jE such that jE = H(CE), and everyoutput on the postE transaction that pays out to theexchange also includes the following smart contract:

“The coins may only be paid to the exchangeafter time tw , OR the coins return to theuser if the user reveals the cancel value cor-responding to jE .”

Then, if the exchange misbehaves by posting a can-celled transaction, the user has can retaliate via a justicetransaction anytime before tw . The justice transactionreveals CE and is posted unilaterally by the user, allow-ing her to claim all the coins in the canceled transactionanytime before time tw (see Figure 4).

Previous transactions. The following notationis useful for our protocol description and analysis. Letpay∗ postE be a puzzle transaction from the currenttrade (where ∗ is either U or E). For convenience, we use

14

the notation prev(pay∗ postE) to indicate the transac-tion from a previous trade that is (a) held by the ex-change and (b) spends the same escrow as the pay∗ postE.Differences from the Lightning Network. Ourbidirectional protocol has many things in common withthe payment channel design of the lightning network.However, there are some important differences. To sup-port coins that don’t have a transaction malleabilityfix, e.g., SegWit, additional constraints are placed onour design. Unlike lightning we can not use the rel-ative timelocking mechanism CheckSequenceVerify [9],instead we can only use the absolute timelocking mech-anism CheckLockTimeVerify [35]. Thus, our escrows al-ways have a fixed time before they must be closed. Ad-ditionally, as discussed in Section 7, due to the threat oftransaction malleability any transactions which requiresignatures from both parties must spend from a trans-action which is already confirmed on-blockchain. Thisrequirement results in a slightly different breach remedymechanism. Unrelated to malleability, our protocol isfocused on trading cross-chain at centralized exchanges,rather than on peer-to-peer payments, so we have theescrow fee mechanism to enable traders to open escrowseven when they do not already hold any of those coins(see Section 3.5).

8.2 Security assumptions.Timelocks. The security of this protocol follows be-cause we set the timelocks to be

τA > max(twA, twB) + 2% τB > τA + 2% (2)

where % is the time required for transaction be reliablyconfirmed on the blockchain. Importantly, notice thatthere is no relationship between the escrow expiry times(twA, twB), which means we can pair any user escrowand exchange escrow, regardless of their expiry time.

Closing escrows in a timely manner. To with-stand attacks by a compromised or malicious user:

The exchange must close its user escrows be-fore they expire at time twA, and its ex-change escrows before they expire at twB.

To withstand attacks by a compromised or unresponsiveexchange:

The user must close her user escrows beforethey expire at time twA, and her exchangeescrows before they expire at twB.

If the user forgets to do this, an honest exchange willclose the escrow on the user’s behalf, but a maliciousexchange may be able to steal coins from the escrow.Also, if a trade aborts or the exchange refuses to coop-eratively close an escrow, the user must sometimes comeonline at a later time in order to recover her coins. Thiscoin recovery periods are only required if the exchangebecomes unresponsive or hacked, and the user will al-ways learn exactly what the coin recovery period is atthe time she attempts to close her escrows.

8.3 Off-blockchain RFQ trades.Before each RFQ begins, we have the following off-

blockchain setup step. This setup could happen at anytime (even immediately after the previous trade).

Setup. The exchange chooses random solution x,computes y = H(x), and sends the puzzle y to theuser. The exchange also chooses a two random cancelvalues CE,A and CE,B, computes jE,A = H(CE,A) andjE,B = H(CE,B), and sends jE,A and jE,B to the user.The solution x and cancel values CE,A, CE,B are kept se-cret by the exchange. The user responds by choosing arandom secret cancel value CU , computing jU = H(CU ),and sending jU to the exchange.

Then, each RFQ is an off-blockchain protocol com-prising the following four steps. In the following pro-tocol description, we assume that Alice specifies theamount of coin she wishes to buy in the Request stage.1

Request. Alice requests a quote, indicating whatescrow she wants to sell coins from, and what escrowshe wants to buy coins from, and the amount of coinsshe wants to buy. If Alice is selling from the user escrow,this protocol uses payE puzzles on the user escrow andpayU puzzles on the exchange escrow. If Alice is buyingfrom the user escrow, we use payU puzzles on the userescrow and payE puzzles on the exchange escrow.

Alice then sends the exchange the following:

1. a payU postE puzzle transaction that (a) locksthe amount of coins she is buying under puzzley. If Alice is buying coins from the user escrow,this payU postE puzzle transaction (b) spends theoutput of the user escrow and (b) can be cancelledunder CE,A. If Alice is buying coins from the ex-change escrow, this payU postE puzzle transac-tion (b) spends the output of the exchange escrowand (b) can be cancelled under CE,B.

As an example, refer again to Figure 1, and supposeafter the second trade in the Figure Alice requests aquote “Buy 2 BTC for some LTC.” In this case, Alicewould send the exchange a payU postE puzzle transac-tion that (a) locks 2 BTC under puzzle y, (b) spendsthe output of the user escrow, and (c) can be cancelledusing cancel value CE,A.

Quote. The exchange responds with the quote—“2BTC can be bought for 200 LTC, open for time δ”. Tocommit to the quote, the exchange signs and sends Alicethe following three items.

1. A payU postU puzzle transaction that (a) locksthe amount of coins Alice is buying under puzzley, and (b) can be cancelled using cancel value CU .If Alice is buying coins from the user escrow, thispayU postU puzzle transaction (c) spends the out-put of the user escrow. Otherwise, this payU postEpuzzle transaction (c) spends the output of the ex-change escrow. (This puzzle is analogous to the

1For a sell-side RFQ, we could prefix the flow describedhere with two additional messages: (1) the user indi-cates an amount of coin she wishes to sell and requestsa quote, and (2) the exchange provides the user withthe quote with the amount she can buy.

15

user escrow

payU_postE

justice

refund

(U Λ E)

U-Wallet

(E Λ tw

A ) (U Λ C

ε,A )

(U Λ E) (U Λ tw

A )

U-Wallet

E-Wallet

(U Λ E)

U-Wallet

E-Wallet

payU_postU

justice

(U Λ E)

E-Wallet

(U ΛX Λ tw

A ) (E Λ C

u )(E Λ τ

B )

solve

E-Wallet

U-Wallet

postU cashout(U Λ E)

E-Wallet

U-Wallet

U-Wallet

U-Wallet

(U Λ X ) (E Λ τ

B ) solve(U Λ X)

U-Wallet

puzzle refund

E-Wallet

E-W

allet

payE_postE

justice (U Λ E)

U-Wallet

U-Wallet

E-Wallet

payE_postU

justice

(U Λ E)

E-Wallet

solve

E-Wallet

U-Wallet

(E Λ X)

E-Wallet

solve0070C0ff

U-Wallet

U-W

allet

exchange escrow

payU_postE

justice

refund

(U Λ E)

U-Wallet

(E Λ tw

B ) (U Λ C

ε,B )

(U Λ E) (E Λ tw

B )

(U Λ Cε,B )

(E Λ twB )

U-Wallet

E-Wallet

(U Λ E)

U-Wallet

(E Λ tw

B ) (U Λ C

ε,B ) (E Λ tw

B ) E-W

allet

(E Λ twB )

payU_postU

justice

(U Λ E)

E-Wallet

(U Λ X Λ twB )

(E Λ Cu )

(E Λ τB )

solve

(E Λ Cu )

(U Λ twB )

E-Wallet

U-Wallet

(U Λ X Λ twB )

(U Λ E)

E-Wallet

(U Λ tw

B ) (E Λ C

u )

(U Λ twB )

U-Wallet

E-Wallet

U-Wallet

(U Λ X) (E Λ τ

B )

(U Λ twB )

(E Λ Cu )

solve(U Λ X)

U-Wallet

(E Λ τ

B )

E-Wallet

(E Λ τB )

E-Wallet

payE_postE

justice (U Λ E)

U-Wallet

(E Λ twB )

U-Wallet

E-Wallet

payE_postU

justice

(U Λ E)

E-Wallet

(E Λ X) (U Λ τ

A ) solve

(U Λ twB )

E-Wallet

U-Wallet

(E Λ X) E-W

allet

(E Λ X Λ twB )

(U Λ Cε,B )

(U Λ τA )

solve(E Λ X Λ tw

B ) E-W

allet

(U Λ τA )

(U Λ τ

A )

U-Wallet

U-W

allet

(U Λ twA )

(U Λ X Λ tw

A )

(B Λ X Λ twA )

(U Λ tw

A )

(U Λ twA )

(E Λ Cu )

(E Λ X Λ tw

A ) (U Λ C

u )(U Λ τ

A )

(U Λ twA )

(E Λ Cu)

(U Λ twA )

(E Λ Cu )

(U Λ twA )

(E Λ tw

A )

(E Λ twA )

(E Λ twA )

(U Λ Cε,A )

(E Λ twB )

(U Λ Cε,B )

(U Λ Cε,B )

(E Λ C

u )

(U Λ twB )

(E Λ Cu )

(U Λ Cε,A )

(E Λ C

u )

(U Λ Cε,A )

(U Λ τA )

(U Λ τ

A )

(E Λ τB )

(E Λ τ

B )

(E Λ X) (U Λ τ

A )

(E Λ Cu )

(E Λ twA )

(U Λ Cε,A )

postE cashout

postU cashoutpostE cashout

puzzle refundpuzzle refund

puzzle refund

puzzle refundpuzzle refund

puzzle refundpuzzle refund justice

E-Wallet

(E Λ Cu )

justice

U-Wallet

(U Λ Cε,A )

justiceU-W

al