Zcash Thorchain Integration Grant

[aiyadt]

Hey @Souptacular

Thank you & ZOMG to consider my request to review the Zcash Thorchain Integration at last minute notice. With Thorchain restarting the network & trading activity mid-October and the Nighthawk Team developers availability for the next 12-16 weeks made this grant review time sensitive. Additionally, China banning crypto operations all the way from trading to mining by Dec 31, 2021 makes this initiative timely, given that China based traders are actively looking for Decentralized Exchanges to trade on. And Thorchain with native coin swaps will surely interest a lot of traders. The alternatives for ZEC on DEX is using ETH based L2 platforms that support tokenized ZEC like WZEC/renZEC, but they have a total circulation of 9k & 16k ZEC only VS the 50k native Zcash we are planning to partner & deploy from Day 1 of trading.

@Souptacular

1. You mentioned in the grant application that you can guarantee T address support, but will need to do more research into Z address support. Can you comment on your conclusions into implementing Z support and how the lack of Z support would affect the privacy benefits Zcash provides? This question is not currently a deal breaker for the grant getting accepted, but we are curious on the status of this feature.

The T-address implementation & usability is a tried and tested model in the wider crypto exchange market. The familiarity of moving transparent coins like Bitcoin, Litecoin, etc by Liquidity Pool providers, Thorchain Node runners & Users who may have not handled Z-address makes the approach of keeping it simple, an important one.

Even if we engineer a Z-addrs based implementation that’s functional, here are some issues with Z-addrs focussed implementation:

1. Implementation can suffer inability of extendability as Thorchain Router software is continuously evolving to avoid 0-days & attack vectors as the xchainjs code exclusively scans multiple public explorer APIs for confirmations and public data to settle trades.
2. Confusion for users & traders alike: recently, a community member had a bad experience with Bitpanda where the pass through service did not like Shielded origins of the transaction. We would prefer avoiding such an issue where a new user withdraws funds from an exchange or wallet and fumbles around shielding/deshielding aspects. Crashed transaction from t-address to t-address
3. In the Zcash community, we realize that Privacy does not come in transit, but in Storage. And I agree with Zooko’s point that shielding of funds should happen at the wallet/storage side, and especially not in a cross-blockchain transactional side.
4. A specially engineered proof-of-concept Z-addrs implementation would be dead on arrival as Unified Address go live in Q1 next year, and we really wouldn’t want new users to Zcash be super confused with T-addrs, Z-addrs(Sapling) and UAs(that contain T-addrs + Orchard Shielded addrs).

Ideally, we expect Thorchain users fund, provide liquidity and trade in transparent ZEC and withdraw their coins to their wallets’ T-addrs which will Auto-Shield them to the latest Shielded pool, per the Shielded-by-Default initiative. New releases to help enable Zcash Shielded by Default - Electric Coin Company

@Souptacular

2. Can you elaborate on your dev hour estimates based on the fact that the Zcash codebase is a fork of Bitcoin which may reduce the amount of hours spent implementing Zcash into Thorchain?

Sorry for the confusion, I’m not sure why so many commenters on this grant have gone great lengths to assume that Zcash codebase being a fork of Bitcoin might reduce the amount of hours spent implementing Zcash into Thorchain. Zcash being a code fork of Bitcoin from 2014-16 era has nothing to do with Zcash integration per Thorchain’s stack of Bitfrost, custom tests & xchainjs wrapper implementation. T-addrs being similar to BTC, BCH, LTC addresses will help from an architectural point of view, but nothing beyond that. The Zcash code will be relevant to ZEC integration and needs thorough development & review before deploying to the Thorchain infra which itself recently had a revamp of the core codebase following an extensive audit. This is why we have planned for 2 developers working on the front end and 2 devs on the backend. We do not want to take risk of shipping hackathon level code to Thorchain devs, especially since this work being the first native ZEC deployment. Follow up implementations on alternate DEXs might take less time following the learnings from this implementation.

The team has estimated 608 number of hours equal to 12 weeks of dev time and includes the development & deployment on end-to-end stack of Thor network, pair programming review sessions to avoid blunders, KT & review sessions with Thorchain devs, boostrapping Thorchain test-net infra, load testing and related tasks. And, I have modified the final milestone payout only after the final delivery of ZEC swaps on the primary Thorchain exchange. Additionally, the Nighthawk team will continue to advocate the multiple front ends of Thorchain(thorswap.finance, brokkr.finance) to implement the ZEC integration as it requires the front end operators to implement the ZEC xchainjs code to enable ZEC swaps. I have mentioned earlier that this is a flat rate grant and we have promised to resolve all outstanding Thorchain Integration issues before the final delivery and such estimates are all included in the budget.