JugglingSwap: Introducing Zengo’s TSS-based Atomic Swaps

TL;DR: With Zengo’s JugglingSwap, trading coins between different blockchains (e.g., trading Bitcoin for Ethereum) can be done in an easy, secure, and generic manner.

Since the advent of Bitcoin and Ethereum, many other credible blockchains have emerged and are still emerging today. With each comes new and exciting aspects and features such as faster settlement, scalability, and richer apps. At Zengo, we believe many of these coins will have utility, so we’ve designed our wallet to support multiple coins. We’ve also solved significant problems associated with using private keys in a blockchain agnostic way.

In today’s diverse crypto ecosystem, people hold multiple coins from multiple chains for different reasons; Bitcoin for holding, Ethereum for DeFi, Tezos for passive staking earnings, etc. Many want to exchange their coins with others. However, securely performing a peer-to-peer swap isn’t so straightforward because the party that sends their funds first is at risk of the other party running away with the money.

After recently releasing our own Swap feature, swaps became one of Zengo’s most popular use cases. As a result, we decided to dive deep into current swap implementations and see whether we could bring a better solution to atomic swaps than those currently available. Following our research, we came up with a new type of swap which leverages the core technology that drives Zengo’s innovative private key solution. The result is a more secure and blockchain-agnostic swap implementation.

We present JugglingSwap, a secure, blockchain agnostic, non-custodial solution to enable cross-chain peer-to-peer swaps to solve this problem. JugglingSwap improves on top of existing protocols in that it allows for a higher degree of interoperability. In particular, it enables transfers between popular ECDSA based blockchains, e.g., Bitcoin and Ethereum and emerging EdDSA blockchains such as Facebook’s Libra, Tezos, and Algorand. 

Today, we release a paper, an open-source implementation of this protocol, and a high-level explanation and demo within this blog.

From the Fair Exchange Problem to Atomic Cross-Chain Swaps (ACCS) 

The fair exchange problem is at the heart of atomic cross-chain swaps (ACCS). There are two parties, Alice and Bob, each with some digital assets. Alice wants Bob’s asset and vice-versa. Alice can give her asset to Bob, but then she’s at a disadvantage because Bob can’t be trusted to provide what he owns.

When a trusted third party is involved, this problem becomes less significant: Alice and Bob will both send their assets to Charlie, and then he will send each party the asset of the counterparty. If one fails to send their part before some pre-agreed timeout, Charlie will refund the asset he has received. Of course, Charlie is trusted to behave faithfully and not run away with their assets (or not be hacked).

Luckily, a blockchain can function as a distributed trusted third party, so it can be expected to act according to pre-agreed rules.

But the problem then shifts to become a governance and “jurisdictional” issue. When a trade is confined to a single blockchain, governance is easy. For example, when Alice wants to swap her USDC for Bob’s BAT, which are both Ethereum based ERC20 tokens, everything happens over the Ethereum blockchain and an Ethereum Dapp (or decentralized exchange, i.e., a “DEX”) which ensures everything proceeds according to the contract.

In contrast, when a trade involves more than one blockchain, the “bridge” between the two assets becomes non-trivial as one blockchain typically is not aware of what happens on another.

This has led to several attempts to construct ACCS protocols, where both Alice and Bob receive the other party’s asset, or nothing happens at all. 

Most prior ACCS protocols used the relevant blockchains’ scripting capabilities and transferred ownership of funds by exchanging signed transactions. These solutions are not generic, as they require specific adaptation that might not even be feasible, per each blockchain pair. They are also not applicable for some blockchains, as they don’t have scripts at all (e.g., Monero and Mimblewimble-based coins like Grin). Because the number of pairs is quadratic in nature, these solutions do not scale well either. 

Recent work introduced the notion of “scriptless scripts,” which enable ACCS protocols without using scripts. This has benefits in terms of blockchain throughput, more efficient swap transactions (identical to regular transactions, thus smaller and cheaper), and also contributes to fungibility and privacy. However, although they do not rely on specific script primitives, they rely on the participating blockchains’ specific signature schemes. 

In particular, they cannot be applied for swaps between established ECDSA blockchains (e.g., Bitcoin and Ethereum) and emerging blockchains that utilize Ed25519, such as Facebook’s Libra and Algorand. 

JugglingSwap in a nutshell (+ Demo!)

JugglingSwap is a new atomic cross-chain swap protocol based on threshold signatures and a novel cryptographic scheme we call Juggling for verifiable encryption of segments of secret keys. 

Unlike known Atomic Swaps protocols that use the blockchain’s scripting capabilities and transfer ownership of funds by exchanging signed transactions, JugglingSwap is purely cryptographic and utilizes an exchange of secrets.  

Roughly speaking, the solution’s main novelty is that instead of sending transactions to each other, the swapping parties are actually exchanging the keys that control the relevant addresses. Since the funds of an address are controlled by the corresponding keys in all blockchains, switching them provides a generic swap solution that is not related to the blockchain’s specific semantics.  

To prevent parties from using the keys they had given away in this swap, we require them to use Threshold Signatures (TSS) controlled addresses (TSS technology is at the core of Zengo’s wallet), such that each party cannot spend funds on their own, but must use a co-signer. Unlike trusted third parties, this co-signer cannot spend on its own and steal the funds. 

Because seeing is believing, we’ve included a proof-of-concept video showing the swap of Bitcoin with Ethereum, using the JugglingSwap protocol.

JugglingSwap proof-of-concept

JugglingSwap: A deeper dive

In our new paper, we consider 2 roles:

1. An owner: an end-user of a cryptographic wallet.

2. A provider: a co-signing service that allows owners to manage funds collaboratively. A secret key is distributed between the owner and the provider: each has its own independent secret share – for example, the Zengo server.

We consider a scenario where 2 distinct owners, each in a setting of a {2,2}-threshold-signing scheme with the same provider (i.e., exactly 2 signers out of 2 allowed signers are required to produce a valid signature), want to exchange funds between them on some agreed-upon amount. 

Building blocks

  1. Threshold signatures – we already mentioned a {2,2}-threshold-signing scheme for the wallets held by each owner and the same provider. Additionally, we’ll use a {3,3}-threshold-signing scheme for the temporary deposit addresses jointly created by the two owners and the single provider.
  2. Juggling: verifiable encryption of segments of secret keys – in the new protocol we describe, a prover can prove to a verifier that a given ciphertext is an encryption of a segment of a secret key of some known public key, under some known encryption key.

If this “known encryption key” is the verifier’s own public key, then the verifier can decrypt (using their private key) this ciphertext into a segment of the desired private key.
Repeating this prove-verify-decrypt process for all pieces of a private key is a method of gradual release: a verifier would be able to eventually decrypt the entire secret key while verifying its progress towards full decryption with each iteration, piece-by-piece.

A simplistic illustration of Juggling’s gradual release – each owner has a private share, represented by a unique puzzle, that they transfer to the other owner piece by piece.

The protocol 

Informally, we’ll use the building blocks mentioned above in the following scheme to achieve a cross-chain atomic swaps protocol:

  1. The two owners and the provider create two {3,3}-addresses, one on each of the two different blockchains. We’ll call them a1 and a2.
  2. Each owner sends the provider a deposit transaction into the {3,3}-address they wish to swap from. The first owner will deposit into a1, and the second owner will deposit into a2. The provider sends both transactions simultaneously.
  3. Once the two transactions are confirmed (each on its respective blockchain), the two owners start executing two interleaving Juggling protocols, to perform a partial fair exchange of their respective secret shares of the two {3,3}-addresses. In other words, – they perform a gradual release of their secret shares:
    One owner is sending the other a ciphertext of a segment of their secret share. The other owner verifies that it is indeed an encryption of a desired secret share segment and decrypts it.
    They then switch roles: the second owner encrypts a segment of its own secret share and sends the ciphertext to the first owner to verify and decrypt it.
  4. The two owners now have 2-of-3 shares needed of the counterparty’s {3,3} deposit address (on their destination blockchain). They co-sign with the provider to withdraw the funds back to their wallet.


The provider is minimally trusted – for availability and fair submission of deposit transactions

In any case, the provider cannot steal funds. They might, under some circumstances, stop the service and, by doing so, freeze funds. However, we have suggested practical ways to ensure that clients can retrieve back their funds in any edge case.

The trading parties (i.e., the owners) are not trusted and can turn malicious. The protocol ensures either both parties complete their swap or no swap occurs at all. 


The two used building blocks, threshold signatures, and Juggling are practically suitable for every existing blockchain. This is because essentially all blockchains use Elliptic Curve Cryptography (ECC) for their digital signature algorithms to transfer ownership of tokens. These signature algorithms rely on the hardness of the Elliptic Curve Discrete Logarithm Problem (which enables Juggling) and support threshold variations (which enable threshold-signatures).

Since this protocol is entirely defined on the cryptographic layer and is agnostic to a blockchain’s underlying scripting language (e.g., Bitcoin Script or Ethereum’s EVM) – it’s pluggable for basically every pair of chains. Even for some blockchains that may not have the necessary scripts at all (e.g., Monero, Grin). Because it doesn’t use scripts, the swap transactions are efficient and comparable to the more efficient recent ACCS protocols.

Moreover, since the variation between a growing number of chains is relatively small and only dependent on the selected ECC parameters, the overhead for adapting JugglingSwap to a new pair of chains is expected to be minimal.

It should be noted that while JugglingSwap solves the Atomic Swap problem, which is the most important building block for swapping, a full swapping solution consists of some more elements related to supplying liquidity and/or matching mechanisms between peers.

Parting notes

As the blockchain ecosystem gets more diverse with new technologies and blockchains, there’s a growing need for simple and unified solutions to allow customers to hold their funds in different coins and assets and transfer them. There’s also a need to perform more advanced actions, such as trading in a secure manner. 

These solutions cannot be based on the specifics of each blockchain, as such solutions would fail to scale with the increase in the number of blockchains. Therefore, only generic, blockchain agnostic solutions are viable for the long term future of cryptocurrencies. At Zengo, we are committed to making this a reality.