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:

1 Like

Oh wow, is it that bad??

1 Like

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.