Decentralized Exchanges (DEXs)

Given the current climate, DEXs are becoming ever more important in the blockchain space. But not only that, they can enable powerful collaborations between projects that couldn’t otherwise work together.

However, personally, I have yet to see a multi-chain decentralized exchange that is actually trustless, safe, reasonably easy and fast. Anyone here has actually used DEXs to exchange ZECs? How was the experience?

Personally, I see great potential for DEXs with Polkadot. Has anyone explored this option yet? It would be a good time to start evaluating the potential as the next network upgrade is going to enable such DEXs:


Oh wow, is it that bad??


i use the most decentralized exchange Binance
honestly wanted to give a try to Decred DEX, but decided to wait for the killer app DEX


Zcash has currently has no bridges to other chains. Therefore the only type of dex currently available is atomic swap protocols. I think there is only one such protocol that supports ZEC.

AtomicDEX (now rebranded to “Komodo wallet” apparently)


Thanks for the feedback @SexDrugsAndZcash & @Milton, appreciated.

All in all it’s looking like the situation is rather dire. It’s kind of what I imagined but I thought I was potentially misinformed on the subject.

@kayabaNerve, from your post on the Binance delisting subject, it is looking like you know all subject quite well. I am sure many of us, certainly me, could learn from your opinion. Would you mind sharing how you see things moving forward, on the subject of DEXs in general, and as it relates to ZEC? If you have one, I would also be curious of your opinion on the potential of the Polkadot tech, to get us moving in the DEX direction. My understanding is they are going to have reliable trustless bridges, and if we are part of those bridges, then we can exchange with all the other bridges (Ethereum, Bitcoin, etc).

1 Like

I inevitably have bias as someone who is developing my own project which is a DEX (Serai). As part of my experience however, I can comment on:

  • Atomic Swaps
  • Multisig-based solutions
  • THORChain
  • Substrate/Polkadot

Per Zwap - Atomic Cross-chain BTC/ZEC swaps - #15, Zcash does not have CTLV and cannot use traditional HTLCs. The Monero atomic swap protocol, as implemented multiple times over, can be applied to Zcash and has been in my former work, ASMR. Please note I’m not confident that work can be deployed as-is, yet it’s valid as a proof of concept.

Multisig-based solutions utilize a multisig to control and secure coins. Most frequently, this is a trusted federation of nodes (see Wormhole). In the case of THORChain, it’s a series of validators who have provided sufficient stake such that they can be slashed on misbehavior with users made whole barring extreme price fluctuations. Serai operates similarly.

The reason for the development of multisig-based solutions is UX. Atomic swaps not only have notable latency (tens of minutes, which is extremely notable to UX), yet a liveness requirement throughout the process. If liveness fails, they lose their trustless properties. To ensure liveness doesn’t fail, one may increase the time period the swap lives for, yet this increases the latency until the coins can be accessed again on failure. Multisigs however can be sent to and generally trusted to make the secondary action (sending BTC in response to receiving ZEC).

The next comment is:

Light client bridges between most PoS systems ARE multisig-based solutions.

When your consensus has a supermajority of validators finalize a block with some sort of multisignature (generally a commit), they’re acting as a multisig. If I bridge 10 ATOM to my brand new Cosmos chain, the Cosmos Hub will only release that 10 ATOM when my brand new Cosmos chain produces a commit claiming such an action occurred. Because my brand new chain’s validators may lie about the existence of such an action, signing a fake consensus commit, my new chain’s validators may steal the coins.

I personally dislike systems like IBC (what Cosmos uses) to transfer coins accordingly because they don’t acknowledge the economics of the bridge status/their validators. This makes sense, as IBC is written as a message passing protocol (as it should), yet that doesn’t change I believe any token transfer system (such as the one built on IBC) should properly acknowledge the tokens it’s transferring as economic units.

To circle around to Substrate/Polkadot, Substrate is a blockchain framework. Polkadot is the premier chain built with it, which runs other chains designed/developed with/around Substrate. One of the main features of Polkadot is how Polkadot-run blockchains (called parachains) can communicate with each other largely without additional trust assumptions because it all ends up at the Polkadot validator set. Zcash cannot bridge with Polkadot, via their own internal functionality, because it is not a parachain.

A Polkadot parachain could build a bridge to Zcash, as any other blockchain network could. If that blockchain network is further networked, it could enable Zcash to become widespread. To be honest, I’d recommend the Cosmos ecosystem if that’s the goal, not the Polkadot ecosystem.

That doesn’t change there must be a bridge built, however. Since Zcash currently cannot evaluate a light client, the only option is some sort of federation/multisig (or technically, instead of having 100 people form 1 wallet, you could have 100 people form 100 wallets like Interlay did. They have individuals provide collateral, are allowed to receive BTC then wrapped into “iBTC”, and are slashed on misbehavior). The leading options for that would be:

  1. Integrating with an existing network (THORChain)
  2. Forking a solution to run under the Zcash banner (THORChain, Interlay)
  3. Getting a new solution (or solution instance) to integrate Zcash (Serai, maybe Ren 2.0?)

#2 would take a notable amount of maintenance effort and would limit scope. #1 would be the quickest and most efficient option, except:

  1. The integration, which received a grant, still hasn’t gone live for reasons I don’t know and won’t speculate on. I’ll solely say someone who can give a meaningful comment should be asked.
  2. If Zcash wants to deprecate transparent addresses, THORChain does not have the infrastructure for a shielded integration at this time.

While a recent forum thread seemed to lean against expanding transparent addresses, they do not sound planned to be deprecated any time soon. Accordingly, my comment is if Zcash wants an immediate solution for a DEX in practice, following up with the existing THORChain grant sounds optimal. If such efforts didn’t already exist, I’d love to espouse the benefits of my own work, yet I won’t misrepresent practicality here. It’s only if Zcash wants another option, either to further decentralize or due to THORChain not being on a desirable time table, would the discussion shift.

Finally, please note some of these solutions offer swaps to other networks, and some offer Zcash on other networks. These are two distinct sets of functionality with distinct desirability.

Also, please note I have no idea what Komodo is doing to integrate AtomicDEX as to the above linked knowledge, Zcash doesn’t support HTLCs. If Zcash doesn’t, and that’s not out of date information, then Komodo would not be performing atomic swaps for Zcash.


Serai DEX will be an important ecosystem for zcash future and every serious privacy coins.

And everyone from zcash community must support the various DEX’S.

And we need more than one options for redundancy.


I now understand much better where we stand. Thanks a lot for this detailed answer, very much appreciated.

Personally, I am not into speculation so speed is not the essence; however I see the following properties as critical:

  • Resistance to governmental interference (properly decentralized - IPFS interface)
  • Provably secure (properly audited, clear code)
  • Support of u/z-addrs

Would Serai be compliant with those properties @kayabaNerve ?

I have mentioned Polkadot as part of a potential technology stack, but I wouldn’t mind Cosmos. However my understanding is that Polkadot does heavily secure the parachains, whereas Cosmos does not share security between chains in the ecosystem. Also a note on IPFS; I see very very few projects taking full-decentralization seriously, yet that’s also something I do see happening on Polkadot ( to get an idea).

I would be very curious to know what other members of the community are thinking of this, and how they believe we should move forward.

Thanks again. This is an important conversation for Zcash.

1 Like

To answer about Serai:

  • No admin keys/council/federation
  • There would be non-economically-secured genesis validators as we can’t have validators sign up in a decentralized fashion before we even launch our decentralized network. Once they phase out, validators will be fully decentralized.
  • Only confirmed UI at this time is a downloaded client (not a hosted website)
  • Written in Rust, already audited our cryptography and bitcoin libraries, planning more audits
  • Would exclusively receive to a z-addr and support sending to [t, z]-addrs. I’m unable to confirm support for unified addresses before I review the licensing around code for unified addresses specifically. My guess is we’d be able to support unified addresses via their transparent or Sapling components (if present)

Substrate, as a piece of tech, is quite flexible and interesting. I personally find it much preferable to the Cosmos SDK. Polkadot would offer security if the chain was to be a parachain, with all the details that involves. Cosmos chains can offer each other security via ICS.

Edit: To clarify, the Serai blockchain is built on Substrate.


Interesting, and unexpected combination. The advantage of being fully independent is quite clear. However, not being part of the Polkadot parachains means that you indeed have to deal with the security, also without being able to access the liquidity present in the ecosystem. Do you feel confident this is the way to go or is it something you are still debating?

Downloaded clients are often a security headache given how many permissions they have, compared to running within a browser. On MacOS, if the app is at least published on the App Store, then it would be running in a restricted environment. If not, hopefully, the app will at least be notarized.

Either way, it’s a very exciting project that I am looking forward to seeing live and successful.


We can still access the Polkadot ecosystem through integrating Polkadot as we would any other project. For us to be a parachain and access liquidity via XCMP would make us trust the Polkadot validators with no evaluation of economic security. With our own integrations, we can track and do our best to ensure economic security.

Polkadot would also only secure the blockchain’s finality and in-ecosystem liquidity. We’d still have to secure all of our integrations.

We’d also have to lock up hundreds of thousands of dollars in order to win a slot and become a parachain (or move to the new coretime proposal which is about ad-hoc scheduling of resources). Even if we had the capital to have our finality secured by Polkadot, I’m not convinced in the stability of their system which we would be largely locking ourselves into.

Finally, if we were to integrate with Polkadot, we’d reduce our own flexibility. Ideally, we end up moving from a synchronous BFT algorithm to an asynchronous BFT algorithm in order to be resilient against even more attacks and enable running validators over networks with increased/highly volatile latency. To use Polkadot would be to hand over our entire consensus to them, which is synchronous.

Downloaded apps are far less vulnerable to hijacking, remove large amounts of infrastructure, and are far more resilient accordingly. While I wouldn’t be against a UI deployed to IPFS, no one has stepped up to write one and I do not personally have the talents nor time.


Thanks again for taking the time to answer all my question @kayabaNerve.

I’m sure this will interest more people so I’ll link this other relevant post of yours, for anyone curious about your project and intentions:

Please let the community know if there’s anything we can do to help and we’ll gladly read any updates you can provide as your project progresses.



Somewhat relevant to working with the Polkadot ecosystem is the interview released today by PGP for Crypto, with Daniel Schöenberger, the Chief Legal Officer of the Web3 Foundation:

@kayabaNerve I understand you have made up your mind and I absolutely respect that. I just want to comment that, as a potential user of your exchange, I can say that I feel good about the Zcash security (although frankly I will feel better once we switch to PoS) and I feel good about the security of Polkadot as well as its parachains. To me, there’s a fundamental question of how much security your fully independent chain will be able to get. I will eagerly wait and see what happens, and cross fingers for your choices to work out.

Serai has a BFT consensus protocol which finalizes blocks. Accordingly, if you run your own node, and only make RPC requests to finalized blocks, the worst which can happen is the consensus equivocates (causing a net split).

To protect against this, every single validator for external networks participates in a cosigning protocol. This acts as a secondary finalization which effectively puts the full stake of every single integration behind a finalized block and detects net splits.

I’m not concerned about our own network’s security accordingly.


Browsers as the de-facto operating system. Over the last ten years, there has been a quiet shift from downloadable applications to in-browser applications. This has been largely enabled by WebAssembly (WASM). Even Adobe Photoshop, long cited as a major reason why many people cannot practically use Linux because of its necessity and Linux-incompatibility, is now Linux-friendly thanks to being inside the browser. This is also a large security boon: while browsers do have flaws, in general they come with much more sandboxing than installed applications: apps cannot access arbitrary files on your computer.” (source: My techno-optimism)

This, I believe, in an important bit to keep in mind for DEXs. Security is critical.

Are you concerned with centralization of browser choices? What’s the difference between trusting a browser and trusting a downloadable application ? I’ve used decentralized DEX’s that run on an application only ( which shall remain anon :smiley: ) but then the issue is distribution. How can folks verify using a: browser or any app is secure? Thanks for your thoughts!

There are a handful of browsers and an infinity of applications. Consequently, there are a very large number of people looking into every little corner of each browser, while there is often a very limited number of people looking into the intricacies of each application.

The browser is like a little fortress between the web and your operating system. When you install an app on your computer, there is not such thing: that app generally has massively more permissions to access various resources. In security design, there is one very important principle, the one of least privilege. That is, an app should exclusively have the permissions that it requires; nothing more. The web browser is close to achieving that for applications running within it.

First, that’s only truly possible with open-source. Anyone can read the code of both browser and app and figure out if it is secure. Obviously, while many are stating this, the reality is only a few are able to read code, and even fewer are able to detect security flaws. That is why it is so important that the code you run is either reviewed by a large number of specialists (which is the case of browsers), or that code has limited privileges (which is the case of apps running inside browsers).

On a computer, there is one practical alternative I can think about: the Apple App Store. All apps are “jailed” and do not have access to the system unless they are specifically given access to it. On mobile, Android specifically, apps are natively “jailed” and do not have much permissions unless manually given specific permissions. I say Android specifically because we can see it in the code of this operating system. iOS UI says it has the equivalent, but no third party has seen the code and can really confirm.

1 Like

So you still need to trust specialists aren’t more motivated by money to potentially look the other way, or back to my original question, trust the few browsers that are available. I love your ideas, I’m simply playing devils advocate.

You don’t. If you really care about this, you can learn and review it yourself. You can hire people to do this for you and then explain to you the intricacies of their finding so you can minimize how much trust is involved.

Personally, I like to keep things balanced. Some aspects I enjoy learning about, some others I enjoy trusting specific fellow humans. Vitalik, for instance, is not paid by Big Browser (pardon the pun) to say that apps are more secure to run within browsers. Most security researchers would agree with his position too.

1 Like

Thanks for your thoughts here! I find the idea of digital reputation very interesting and its surprisingly hard to define and explain because it seemingly takes time to develop and time is so very precious. Again, I’m fully onboard with open source and the least privilege ideas, its just I’m not convinced the browser is the answer. I really like the freedom to choose! :heart_eyes: :zebra: