@aiyadt I know you mentioned in a post that you aimed to get started on Oct. 1, but you only posted the hourly rates and expected hours breakdown earlier today and ZOMG would like the community to have more time to comment on and for you to respond to comments on the hourly rate breakdown/number of dev hours required as well as the questions @hanh pointed out. During our ZOMG meeting today we had discussed your grant and have some specific questions for you:
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.
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?
To a first approximation, using t-addresses for this instead of z-addresses has no privacy impact on the users. The users get privacy from their wallets (Shielded By Default wallets), not from the services they interact with. As far as I understand it, a public service like a bridge should use t-addresses in order to provide transparency to the public about the coins it is holding, while a wallet should be Shielded By Default in order to provide privacy to the wallet’s user.
So as far as I understand, this is a non-issue. Adding zaddresses into the THORChain bridge would reduce the public’s visibility into the operation of the bridge without improving privacy for any users.
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.
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:
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.
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
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.
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
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.
The ParseMemo is a TC related method and the commit does qualify for duplication across various supported chains to get them communicating. It does not imply that rest of the wallet, transactions and trade router code is the same.
There are total 5 resources: 4 Devs and 1 PM. The Dev resource responsibilities overlap with the Development & Testing + Integration & Planning + Deployment budgets.
No, Thorchain does not support Shielded addresses as it is primarily a DEX with a complex network of LPs, node runners and transaction routers.
And yes, following this grant completion, anyone would be able to swap directly out of BTC or ETH to ZEC on their Thorchain’s T-addrs wallet and then withdraw ZEC to their non-custodial wallet which will Auto-Shield their ZEC. (note that there will be added fees paid in RUNE/THOR token, but users do not need to purchase any tokens, all the conversions are done on the fly and fees are paid via the input for the swap).
To be clear, my comment is purely from an implementation point of view. I just greatly disagree with the cost estimate.
In my opinion, forking their bitcoin client and adapting it for zcash is a matter of hours or days. It includes all changes needed.
Normally it wouldn’t be the right thing to do because it duplicates code but that is the direction they have already taken.
There would still be deployment and infrastructure costs.
I suggest that we open this grant to other developers. If indeed no one shows up and the community considers it is worth 200k, then it may be the right thing to do. However I have a feeling that the benefits will not be as good as the costs specially when they could have been 10* less.
Isn’t it true renZEC or wZEC (is there such a token?) require going trough one intermediary (possibly centralized / small number of validators and subject to regulatory pressure) and then using an AMM on Ethereum and then back out through same intermediary to whatever native chain you like? That is minimum three steps (perhaps more, each with their own ETH gas fee) to go between zec to btc (as an example) without CEX. Wouldn’t thorchain reduce the number of steps? This may make easier for new users who don’t know have to navigate ethereum defi to trade and get zec.
Plus ethereum can have insane swap fees (not sure thorchain’s swap fees), so there is benefit to having another option. Also benefit to having another option as a backup for ethereum option. There can still exist thorchain and ethereum AMMs, better to have both serve as backup DEX’s for each other.
Thorchain may also draw out more zec liquidity which will potentially help with zec price since liquid assets trade greater than illiquid in general.
AFAICT, renZEC does not require going through a single intermediary. They use a pool of darknodes to do the cross chain transactions.
If I was a liquidity provider, I would choose the pool that gives me the best ROI. Usually, it means going for the larger ones. IMO, the Thorchain pool size isn’t very competitive to the likes of Uniswap.
There is a risk of having ZEC liquidity spread thin by having too many pools. IMO, the liquidity of wrapped ZEC is currently quite low and Thorchain isn’t attractive enough to convince new liquidity providers to enter their network. They have had a few hacks recently that have tarnished their reputation.
Those are fair points and the hacks are indicative of premature deployment and auditing. Not a good look. However thorchain does have some big names pushing it (Vorhees, et al.?) so I’m assuming it will eventually be robust, perhaps not though.
Nonetheless, it is possible the low levels of liquidity on ethereum right now are due to the tucked-away nature of the renZEC pools amidst a plethora of other defi products. I wonder if thorchain having a brand as a native swap chain (instead of ethereum which has ten million things going on) will make a difference.
This is quite possible indeed. I’m not sure the solution is to have another competing provider. Maybe improving access and liquidity would have a more direct impact.
It’s also because I don’t think the integration with Thorchain is the best route for ZEC adoption in Defi.
I believe in the free market and that projects should be valued based on offer/demand.
We want to build a community around projects and devs. I’m just giving my opinion.
Even if I’m right but no one wants to do this project for cheaper, then it is still the best offer.
I definitely agree with your sentiments around soliciting and weighing the best proposals, though I worry about the risks of staying on the sidelines too long. I’m not in a position to second-guess anyone’s analysis about exactly how much work/costs this project ought to entail, but in the grand scheme of things it does not strike me as an unreasonable amount of money to spend given the potential return on investment.
Would you mind elaborating on your view of the best route for ZEC Defi integration? I am genuinely very interested to know.
Thorchain has the best ROI with 20.797% Average Liquidity APY THORChain
Wrapped coins are IOUs and such tokens are susceptible to censorship, surveillance and blacklisting.
Native integrations open up novel implementations as any front end can use Thorchain as a backend to do swaps between various coins. Several benefits of integration with Thorchain have been shared here Zcash Thorchain Integration Grant - #56 by aiyadt
Thorchain does improve access for Liquidity Providers in a decentralized manner, IMO there is no better DEX than Thorchain network right now, especially after their recent audits and insurance + bug bounty programs.
2 more bonuses of this grant getting funded:
We onboard 3 new developers to Zcash ecosystem.
We open up the possibility of price discovery for ZEC on a Decentralized Exchange, where the demand can be driven by the need for privacy VS a CEX where the miners/bots/arbitrage can keep ZEC trading in line with other CEXs.
Thorchain fees are defined here 