What is Subatomic Swaps and how it fits in Atomic Swaps architecture

Satinder Grewal
12 min readNov 25, 2021

Some days ago a community member asked questions regarding Atomic Swaps and Subatomic Swaps, for which a nice discussion happened in Komodo Discord. It seems nice conversation covering a lot of important things and FAQs.

Just making it’s copy here for references.

Direct Discord chat link from where this conversation starts: https://discordapp.com/channels/412898016371015680/676136067262447633/703896480502775859

Diablo_ 04/26/2020
Hello smart people.
I find the idea of subatomic swaps fascinating, but I’m wondering how the future outline for subatomic swaps and atomic swaps look like as, as far as I see, they tackle the same problem and have the same goal: allow (almost) trustless p2p/otc trades.

Will they both coexist next to each other? Are the differences significant enough to justify the existence of both techs (considering split userbase etc.)? If so, what exactly are meaningful differences?

Two examples I see (correct me if I’m wrong), is that subatomic swaps allow partial filling of orders while atomic swaps do not, and atomic swaps are trustless while subatomic swaps are “only” heavily trust-reduced/risk-reduced.

Are there maybe differences regarding performance, simplicity of the tech, UX or regarding the potential amount of supported coins/protocols?

grewalsatinder 04/26/2020
composing reply
I hope this reply also turns to an article. I usually write descriptive on the spot chat replies :)

Diablo_ 04/26/2020
Would be great for sure :)

grewalsatinder 04/26/2020

Will they both coexist next to each other? Are the differences significant enough to justify the existence of both techs (considering split userbase etc.)? If so, what exactly are meaningful differences?

Yes, as per current protocol developments, both protocols can co-exist without any issue for long term. I believe these both protocols, DEXP2P and MarketMaker version 2 (mm2) will both complement each other.

Subatomic swaps are originated after DEXP2P tech development done on Komodo’s core daemon. The need for DEXP2P arises out of the necessity, where MarketMaker v2 need more scalable and faster messaging layer to communicate between it’s network to negotiate and connect to trading parties who wants to trade a pair of coin, and every other node who wants to know what are the orders other nodes in the network are offering so they can initiate an trade with each other.

With MarketMaker I believe the messaging protocol was based on torrent, whereas in Komodo this messaging is built using libevent library.

Basically there are two different methods of communicating of computers over the connected network. torrent’s method been good, but James found bitcoin’s own code using libevent for communication is much superior and he worked more than a month on it to port that libevent based communication layer to create a new communication network. From around December 2019 to January 2020, he worked on creating, testing, improving DEXP2P technology, which basically starts a peer-to-peer network with just adding a parameter -dexp2p=2 to an Antara Smart chain.

From January 2020 onwards once this DEXP2P network layer creation technology solidified, James push this technology to it’s limit and test it further to make sure it can handle huge loads of network traffic in case it is used for AtomicDEX protocol’s network, messaging and communication layer, where in a scenario millions of users might be using AtomicDEX protocol to make decentralised trading.

This testing from January 2020 to February 2020 gave us further advancements to DEXP2P where it was even possible to transmit live video feed over this peer-to-peer network of equally high resolution and high-bandwidth rate as equally you see over YouTube or everywhere else with 1080p to 4k resolution video. Gigabytes of data can be transferred and over DEXP2P’s broadcasting API calls to the subscribing users over a P2P network, on it’s full capacity this load is divided between all nodes and every subscribing node is ensured to receive the data even if they join the streaming video later. And this data is available to receive by the participating nodes for approximately an hour or so.

The testing of video streaming over DEXP2P made communication layer p2p network showcased how strong, tougher, resilient, scalable DEXP2P technology is, which as of today’s date I guess no other peer-to-peer network is providing such functionality or feature.

The sole purpose of DEXP2P is to just create a sub-network of it’s own just for communication between participating nodes.

It is not necessary to have this DEXP2P be connected with a blockchain or a cryptocurrency, but it is indeed possible to make the network communication work in a way that this communication messaging over DEXP2P can be used for wider spectrum of cases.

For example, it is possible to broadcast set of files over DEXP2P network over Subatomic configuration, for a set price. The Bob nodes can define these set of files with the price they are accepting to broadcast these files to the Alice nodes when accepting the negotiated price. This means the Subatomic CryptoConditions DApp already allows selling files over peer-to-peer network for a currency which is defined in “subatomic.json” settings by Bob nodes. And these files can be defined to be sold in multiple currencies at once.

So, all the above must clear to you the reasons:

  • WHY DEXP2P came to existence: For faster, scalable communication medium for Marketmaker v2.
  • WHAT it can do: With default set of messaging format, it can be used more than just a communication medium and be used for creating different level of P2P apps with a mesh of other existing CryptoConditions based DApps and/or creating an one for special purposes with specific use case based on ideas an innovations from community developers.
  • And WHAT it is capable of.

The differences if still not clearer, Subatomic is a DApp based on DEXP2P technology.

And AtomicDEX is an independent set of protocol with independent codebase written in Rust language providing an API serving daemon called “MarketMaker” (mm2).

The Subatomic CryptoConditions DApp avoids blockchain based messaging and communication to negotiate, and instead uses DEXP2P based communication, resulting in a lot faster negotiation between to trading parties. As a result this we get the following:

  • Possible to trade micro transactions.
  • Super Fast communication between trading nodes resulting very very fast trades.
  • The trust factor moves from blockchain side communication to subatomic’s protocol where you can trust and distrust the trader on network by identifying it with its pubkey linked with the trades.
  • Subatomic is ideally useful for small trades only. Example if you want to to trade $100, you must use small portion of the trades of this $100 on Subatomic swaps, since these are faster, and in any case the other party does not fulfil the other rest of the trades, you won’t lose much of your capital in these trades. As of now it allows all these trades not simultaneously with any API, but this can be simulated if you execute subatomic trades command yourself in multiple terminal tabs/windows. So, this feature can be customisable coded in GUI by the GUI developers.

On the other hand AtomicDEX gives the following:

  • Allows trustless trades in all of it’s process
  • Allows big volume trades on all supported cryptocurrencies if offers to support (almost 99% of current market cryptocurrencies)

You can expect that some point in future AtomicDEX will adopt the DEXP2P networking layer to make even more solidified peer-to-peer communication in it’s network, and that will help scaling AtomicDEX far beyond what it already can support scaling it.

@SHossain @jl777c please find any errors in my description and help me fix it.

grewalsatinder 04/26/2020

Will they both coexist next to each other? Are the differences significant enough to justify the existence of both techs (considering split userbase etc.)? If so, what exactly are meaningful differences?

Yes, as I see they will coexist to each other. Subatomic DApp based on DEXP2P technology itself creates another level of micro-transactions based swaps on this network which can swap new set of GUIs based on this DApp’s API. And that’s exactly what I’m trying to cover.

Because Subatomic relies for communication and negotiation based on DEXP2P instead of some parts of it being negotiated via blockchain it allows to trade with ANY bitcoin compatible blockchain. This has also allowed making a subatomic swap of Shielded transactions only blockchain (zk-SNARKS) with transparent transactions blockchain, like PIRATE and KMD. We have also tested pure PIRATE to PIRATE trades over the network as well. That means any blockchain over the network can also do trades purely between Shielded addresses, like for example PIRATE’s shielded Address funds being traded with Veruscoin’s shielded address funds. This means ANY zk-SNARK family blockchain can trade their funds with each other in pure shielded transaction zone. That is superb feature of Subatomic CryptoConditions DApp.

But note that to allow trading of shielded addresses with other shielded address over the network that blockchain must have zviewingkeyAPI coded in it. If I’m not mistaken with the required API. I guess it is some other API, may be @SHossain can correct me with that API reference.

This must clear the main differences what Subatomic swaps can do, what AtomicDEX swaps so far can’t do. Also must be clear how much the trust factor there is in Subatomic swaps vs the AtomicDEX’s atomic swaps which are 100% trust-less, whereas with Subatomic swaps there is some level of trust which can be mitigated with only doing small trades or bigger ones based on the trust you put in specific known or unknown pubkeys.

SHossain 04/26/2020
Verus needs to implement zviewingkey for their shielded addresses to be working fine with subatomic. Until they do, ztx for Verus on subatomic is not fully supported. Transparent addresses works just fine.

grewalsatinder 04/26/2020

Two examples I see (correct me if I’m wrong), is that subatomic swaps allow partial filling of orders while atomic swaps do not,

I guess both protocols, Subatomic swaps and AtomicDEX’s atomic swaps allows partial filling of trading orders in. Need some other dev/tester member’s seal on this comment. @SHossain

and atomic swaps are trust-less while subatomic swaps are “only” heavily trust-reduced/risk-reduced.

Yes, atomic swaps with AtomicDEX are 100% trust-less, but there is only a variable degree of trust with Subatomic swaps. The known pubkeys shows the known traders on the network with whom you can possibly put more trust and initiate bigger volume trade orders, based on your own discretion. And over time you can also note specific unknown set of pubkeys which you trust and add to your own list of trusted pubkeys which you can possibly trade variant of trade volumes. I see this exactly setup in a way where on LocalBitcoin.com I would add some traders on my trusted list after doing several trades of different volumes and remembering who to approach in case I later need to do large volume trades. In this case Subatomic swaps with Subatomic App work like an escrow free trades where Subatomic App performs the role of escrow doing subatomic swaps of set pair of coins.

SHossain 04/26/2020

Subatomic swaps and AtomicDEX’s atomic swaps allows partial filling of trading orders

that is accurate. subatomic also allows full 100% order fill

grewalsatinder 04/26/2020
cool!

grewalsatinder 04/26/2020
Are there maybe differences regarding performance, simplicity of the tech, UX or regarding the potential amount of supported coins/protocols?

the backend API for both MarketMaker v2 (mm2) and Subatomic DApp are different. Both has their own variance of differences, but even as a command line user I don’t feel much of trouble using both of these APIs to perform swaps on each network. My experience is majorly with subatomic swaps instead of mm2 so I can confidently say it’s too simple and much faster experience with subatomic swaps.

The GUI application puts a lot of work to make the process of both of these swapping/trading protocols as easy as much possible. That’s why the end user will not feel too much of degree of difference in user experience. Different versions of mm2 based GUIs and subatomic based GUIs will have various level of differences in it’s graphical application and user experiences. I’m very confident users will find more options and various level of easy to detailed experience with both set of protocol based Graphical Apps.

I must clear that AtomicDEX supports lite wallet based swaps using SPV protocol so far, where it is possible to use nSPV based atomic swaps with AtomicDEX too, just need to code that ability in the core API I believe, and then code that to GUI.

With Subatomic swaps the idea was to solidify the initial work to make it work, and take to to the stable state. That is why Subatomic swaps so far mainly support only Native mode based trading. It must be possible to add support of nSPV with subatomic swaps since both nSPV and subatomic CryptoConditions are built into Komodo’s core codebase. But how much work it could be only core developers can explain. I just hope it wouldn’t be huge work for some skilled core blockchain developer.

As I understand subatomic support all those cryptocurrencies are derived from BTC codebase, much like AtomicDEX supports various Bitcoin based cryptocurrencies. But Subatomic supports doing the trades with shielded address right now, whereas this feature is yet to be expected from AtomicDEX soon sometime in future. I can’t comment what level of technical hurdles there might be to support ETH and other non-bitcoin based cryptocurrencies with Subatomic swaps.

@dukeleto did I answer any of your queries in my answers? Feel free to jump in if anything else I can answer… may be :thinking:

Diablo_ 04/26/2020
Thanks for the great answers, they clear many questions about the technical side especially.

What I’m still not quite sure about is the view from a user-centric perspective. From the technical side one big advantage for subatomic swaps currently is the usage of DEXP2P as a much more efficient communication layer, but as you said it can (and likely will?) also be used for AtomicDEX once someone is willing to do the work, which makes the technical side again pretty close between subatomic and atomic swaps.

So what about the user view? What advantages or disadvantages do they have with both techs — once AtomicDEX also uses DEXP2P for communication? When would one prefer atomic swaps and when subatomic swaps?

As you say AtomicDEX supports trades of any size as there’s simply no limitation for it. Subatomic swaps on the other hand work best for smaller trades as it is only trust-reduced — but is that really true? Can’t subatomic swaps just split larger trades into more (sub)trades, meaning at any time of the process there’s still only a small amount of money at risk? Or is there some technical or performance limitation which makes is infeasible to e.g. automatically split a $10k trade into 1000 $10 trades?

Diablo_ 04/26/2020
To put it bluntly, I’m still having a hard time to see a good reason for both techs co-existing next to each other in the long run. Sure, currently the tech behind it differs to a larger degree (DEXP2P), but that’s only a temporary state until AtomicDEX also moves to DEXP2P. Once that is done there are of course still some differences in the underlying tech, but they achieve almost the same for users with almost the same user experience and with almost the same limitations? Of course competition is never wrong, but doing so in the same ecosystem (KMD) is surprising to me.

jl777c 04/26/2020
atomic swaps will take more time, but is trustless

subatomic swaps are much faster (also non-coins can be swapped, like files), but requires trust or making it small enough in size

these are two almost totally independent cases, so not sure why you are surprised they are both being worked on

maybe in real world terms, it is like supporting both credit cards and bank wires

grewalsatinder 04/26/2020

So what about the user view? What advantages or disadvantages do they have with both techs — once AtomicDEX also uses DEXP2P for communication? When would one prefer atomic swaps and when subatomic swaps?

true, AtomicDEX can gradually make it possible to trade both subatomic + atomic swaps. But note that “Subatomic” is a CryptoConditions DApp.

AtomicDEX is based on mm2 API, it is a separate daemon, separate codebase and logic of its atomic swaps is different than subatomic swaps.

I see that subatomic swaps will be possible with komodod API.

So, you are basically pointing if a GUI can adopt both mm2 API and subatomic API from komodod, which is true. It is possible.

jl777c 04/26/2020
bankwires take longer and dont require trusting the other party to not do a chargeback. credit cards are faster, but you do need to trust the other party wont do a chargeback. so if someone accepts bank wires, they shouldnt accept credit cards?

Diablo_ 04/26/2020
Aren’t both techs close to “instant”? Maybe that is indeed what I’m missing.

jl777c 04/26/2020
no, atomic swaps require confirmations or even notarizations

grewalsatinder 04/26/2020
with AtomicDEX the trade initiates with the blockchain based negotiation and including the secrete and redeem scripts.

This communication requires the blockchain confirmation time, which highly varies from blockchain to blockchain.

BTC = 10 minute block
ETH = 10 to 2 second block?
KMD = 1 minute block

Diablo_ 04/26/2020
Right!

jl777c 04/26/2020
minutes, fractions of an hour, though if both parties are willing they can reduce the number of confirmations needed

grewalsatinder 04/26/2020
so AtomicDEX is blockchain time based
subatomic is based on network message time based!

jl777c 04/26/2020
subatomic swaps are pretty much done in seconds, about 20 seconds is what i see
so 20 seconds vs 20 minutes
seems a pretty big difference
but the alice node is totally trusting the bob node for each subatomic as alice sends first

Diablo_ 04/26/2020
That’s a good point, thanks. That subatomic swaps support non-coins also opens up additional use-cases.

jl777c 04/26/2020
i can imagine a gui that makes both methods look nearly identical
zaddr are immediately supported with subatomic

Diablo_ 04/26/2020
Does the current subatomic implementation automatically split the trade into multiple trades already?

jl777c 04/26/2020
not at the low level, but nothing stops the GUI from making multiple requests

grewalsatinder 04/26/2020
i can imagine a gui that makes both methods look nearly identical
zaddr are immediately supported with subatomic

My major focus will only remain on subatomic as a priority, but I really hope I reach the point where I can also utilise mm2 API can it’s trading volume with my project sometime in future. :slight_smile:

I since I have now adopted Go language I really hope some other go language devs join me in my journey too.

jl777c 04/26/2020
i think the GUI should allow the user to specify the maximum risk that is acceptable, different levels per pubkey or type of pubkey

--

--