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:
- Integrating with an existing network (THORChain)
- Forking a solution to run under the Zcash banner (THORChain, Interlay)
- 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:
- 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.
- 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.
