Newb here, but I agree.
We need native ZEC represented on Thorchain.
This is a short term project with long term value.
If hires can be made quickly and it doesn’t delay the existing grants, we need to pull the trigger.
Volume is going to skyrocket when the MCCN caps are raised in the coming months, and we should to be ready.
Thanks for your support & feedback on the Block Explorer grant @tokidoki , as mentioned earlier, we will be delivering both Zcash Block Explorer & Nighthawk Wallet Milestone 1 as per the existing grant milestones prior to receiving the funds for Milestone 1 of Thorchain Integration Grant.
For setting up THORNode - both testnet and mainnet ( for testing purpose ) , we will be using Amazon Elastic Kubernetes Service ( EKS) .
as for the instances in the K8S cluster, we would be running instances with at least 16 vCPU and 32 GiB Memory with local SSD.
why do we need to run so many instances ?
each THORNode is comprised of 5 major components:
thord - this is a daemon that runs the THORChain chain itself
thor-api - this daemon runs an HTTP server, that gives a RESTful API to the chain
bifrost - this daemon creates connections to remote chains (like Bitcoin, Ethereum, Binance, etc) to both observe activity on those chains (incoming/outgoing transactions), and also sign/broadcast outgoing transactions (moving funds on remote chains).
thor-gateway : THORNode gateway proxy to get a single IP address for multiple deployments
midgard - this daemon is a layer 2 REST API that provides front-end consumers with semi real-time rolled up data and analytics of the THORChain network. Most requests to the network will come through Midgard. This daemon is here to keep the chain itself from fielding large quantities of requests. You can think of it as a “read-only slave” to the chain. This keeps the resources of the network focused on processing transactions.
Full nodes - for every chain that is supported by the network, each THORNode operator will run their own full node of each chain (Zcash, Bitcoin, Ethereum, Binance, etc).
for all the HTTP services mentioned above, AWS Application Load Balancers will be used.
Also costs for DevOps is included in the $20,000.
An in-depth discussion on What is Thorchain? and How it works via Clubhouse
Well here is an example of bad quality.
What kind of commit is this? It’s absolutely useless for anyone who wants to reuse, improve or debug work done so far.
No serious project would accept this commit.
Overall - if you look at the commit history of the nighthawk-wallet-android repository the work done in the past year looks extremely trivial without any substantial progress.
It looks horrible to be honest.
Hi everyone - catching up on this thread and wanted to clarify a few points.
First off, I’m thrilled to see there’s interest from the community to make this integration happen. I believe it’s very strategic for Zcash for several reasons:
To be clear, I approached Nighthawk regarding this development. I (and ECC) are fully supportive of them taking on this grant, and given their expansion, I don’t see any reason why this should interfere with their plans for the wallet that they committed to in their previous proposal.
I’m glad to see the community demanding transparency and accountability with how grant funds are disbursed and how the community regulates itself. These are the types of questions we should be asking! But I don’t think we should infer bad intentions, given the role Nighthawk has played in the ecosystem.
If another developer team would like submit a proposal, that is of course within their right to do so and I think competition is healthy to promote best execution. But we should not let it detract from the progress being made on this initiative.
It’s a merge commit. The work is in the source branch.
Since it’s non-shielded ZEC being discussed, what’s the issue with simply forking the existing BTC/BCH/LTC/DOGE code? Yes, I understand node infrastructure and testing must be done, yet this wouldn’t require original code unless you expand to shielded ZEC as you noted as a ‘possibility’ and not a guarantee.
I don’t have weight in the ZCash community, nor much experience, but I’m personally against this, not only due to grant size, yet also due to a personal dislike for Thorchain. They have incredibly sloppy code (those 4 BTC coins? They don’t use the same code. They copied/pasted the folders and have different instances they update with the exact same edits) and have recently suffered multiple exploits.
Also, it’s important to note while ZEC doesn’t leave the chain, neither does the BTC used in WBTC. When you stake on their platform by providing liquidity, you transfer ownership of your coins to a multisig. Granted, a multisig with a bunch of people meaning your coins are very likely to not get stolen by the people in it, yet it’s still a multisig and actions are taken by the automatic decisions of another network with its own consensus. If that counts as staying on the L1, then so does WBTC, at which point the distinction becomes meaningless.
As for actual swaps, you have no guarantee you’ll get your payment as you do in an atomic swap. “in a permission-less and non-custodial wallet” You literally send your funds to the multisig and then expect the people behind the multisig to be running code which pays you out. If Thorchain gets exploited again, and don’t have the funds to complete pending swaps, you don’t get any funds out (until they step in with their treasury to reimburse users, if they continue as they have). With atomic swaps, you’d at least get a refund.
Part of this is my personal bias, as I do understand the fact the multisig is almost guaranteed to act as the code expects. I’m just saying the marketing can be very misleading, and their code shouldn’t be trusted according to its own history. With maturity, maybe, and they are rolling out a new feature to automatically detect insolvency. That said, it only detects insolvency AFTER it becomes insolvent, and crypto systems should never ask “have I broken?” They instead shouldn’t break (unless a chain reorganizes, yet this system runs on a timer and is in response to exploits, not reorganizations).
Personal distaste aside, I do think wider support for ZEC would be beneficial. I just think this grant asks for too much for too little and the value of Thorchain should be properly considered.
TL;DR What’s stopping you from copying the BTC code yet again? Marketing can be very misleading. I personally dislike Thorchain for reasons which may be seen as valid or petty.
Thanks for your feedback Luke.
If it was possible to simply fork BTC code for ZEC to make the Zcash Thorchain integration happen, this task would have been just a 7-10 days effort to make a PR upstream.
The fact that the ETH Bitfrost wrapper was exploited earlier today shows how much critical piece of software it is. The Bitfrost code for Zcash will be similar to Bitcoin, but not the same, and requires heavy testing and hardening before shipping to production.
(more details on the ETH exploit here THORChain Suffers Another Exploit)
Note: This exploit affected the Node runners & LPs directly, and not the end users who were using the DEX for native swaps. The native swap action does require “trust” in the decentralized Thorchain network to be up and running. So it is to be noted that an investment towards this integration does result in entrusting the capabilities of the Thorchain core dev team to keep the DEX infra functional. Thorchain devs have been very professional in designing the architecture and performance of the Thorchain network, but they too rely on the stability & performance of the Bitfrost code for each of the supported native coins. ETH, with it’s multitude of implementation has just made the node code complex and target for exploits. For ZEC integration, we will rely on the zcashd core and do not expect exploits. If we happen to see an exploit, then we have the backs of both Thorchain & ECC core devs to help fix the flaws in the zcashd which would also be beneficial for the entire Zcash network to identify and fix flaws found while using zcashd for novel application like native swaps.
Personally, I am not a fan of wrapped assets that are held by centralized authorities which would only release the funds per KYC while having the ability to freeze coins/tokens. Wrapped assets are not fungible.
… why wouldn’t it be possible? The support for BCH and LTC and DOGE shows this model has worked for them in the past. I fully understand shielded ZEC would be a much more involved work, notably due to their TSS algorithm, but again, that’s not in scope for this proposal.
The swap action does require trust the network will continue working. You send money to them with a memo. The network sends out the matching amount of funds in the specified currency. There is no cryptographic guarantees in place on the end user’s side (such as a timelock).
These are held by authorities, not by the end user. It’s just a set of authorities of such quantity it’s improbable they’ll run off. I agree it’s better, but there’s a lot of similar concerns (with a much decreased chance of happening).
As mentioned earlier, there is no re-useable code. And the work planned for this proposal is per the estimates of developers who will be working on this integration & their discussion with Thorchain devs.
As mentioned earlier, they have a working BTC codebase and ZEC is a BTC derivative. They also already reused their BTC code for other BTC derivatives. Would you please explain why it isn’t reusable in this case? If it truly isn’t, I’m happy to accept that, but it should be for the scope guaranteed by this proposal.
Again, I understand it wouldn’t be usable for shielded ZEC; you yourself defined that as not part of this grant (at least, not guaranteed as part of this; solely something to look into).
Sorry if I should’ve edited the previous post, yet just to add an addendum, I did consider one reason why it makes sense to have multiple implementations of BTC copied around; RPC variations. I wish the Thorchain developers had used a trait for the BTC RPC and never created duplicate code, yet they didn’t, unfortunately. While I don’t suggest that be done as part of this grant, of course, I will say even if the RPC isn’t directly compatible (stopping immediate reuse), surely migrating RPC variations would be quicker than a complete rewrite (cited at 228k).
Pricing based on the guessed value of the outcome seems strange to me, I’d rather have the project be priced based on effort.
Who knows whether or not implementing this will increase the price/adoption, there have been many examples of ZEC becoming more liquid (via exchange listings etc.) with no corresponding increase.
This one is too expensive in my opinion.
The ZFND Grant’s budget section is open to grants targeted with the value it will bring to the ecosystem. It reads “Convention has been for applicants to base their budget on hours of work and an hourly rate, but we are open to proposals based on the value of outcomes instead.”
For the budget breakdown, see point 6 Zcash Thorchain Integration Grant - #7 by aiyadt
Thorchain implementation enables native ZEC swaps, we are not aiming for increasing liquidity on CEX, but unlocking large LP’s Zcash holdings and ultimately providing a safe harbor for Zcash trading in the event of temporary regulatory attacks on CEX.
Hi @aiyadt! ZOMG met last night and the main thing we discussed was the question of timing. We totally understand your reasons for wanting to get this grant approved before the Block Explorer grant concludes, and it looks like that work is going really well based on your latest update and the live beta.
That said, a few members of the committee felt strongly that we should wait until all of the deliverables in the Block Explorer grant were 100% completed before approving another grant.
We realize there’s some inefficiency and risk here, since there might be some delay where your team is in limbo between projects, and there’s some risk we’d say no, or a risk of delay.
But on the other hand, waiting until the other grant is complete will give all of us as ZOMG members—and the community here—a chance to try out and evaluate the full chunk of work you’ve done on the previous grant before making their final decision on the next grant application.
Again, we totally see from your side how this creates some uncertainty for you, and I hope you’ll also see our side of it too.
Since we’ve already discussed the project quite a bit, I think there’s a good chance we’ll be able to make the decision quickly once the other grant is complete. There’s no reason for it to drag out.
The other important thing we need to move forward is some breakdown of expected hours and hourly rates. These can be estimates, and we get that great engineers fetch high rates, but we need that to move forward.
It may be true that it says this, but we are still figuring out the best way to do our jobs as a committee, and in this case both for transparency to the community and for our own internal deliberations we need to see actual estimates and rates. This will let us do the due diligence to check that the estimates and rates seem reasonable.
We appreciate the work you’ve put into making a model for the estimated financial impact to the Zcash ecosystem, and that is a legitimate and cool way of thinking about it, but in this case (and I expect in the future for most other projects) it’s just not enough for us to go on, so we will need the hours/rates breakdown to move forward.
Thanks for your work on this, and thanks for engaging constructively with all of the questions here!
Thanks @ZcashGrants
I will get the Block Explorer devs to prioritize wrapping up the final deliverable. And also work on a breakdown of expected hours and hourly rates for the Thorchain Grant.
I wrote that, so let me chime in 
We are still open to the “outcomes/value” pricing. But I think the unstated assumption is that there needs to be a convincing way of estimating that value. Perhaps even building in some success-based award function. At this point I don’t think we have what we need, or this is not the right use case.
Lots has been said about other topics on this thread, so I’ll keep my comment to the above.
I think it’s worth noting that thorchain was exploited again, that’s now twice in 7 days. The hacker left this statement in the memo-"Could have taken ETH, BTC, LTC, BNB, and BEP20s if waited”
I believe this quote from @aiyadt about the previous exploit applies again, so for example if this grant was funded & implemented in Nighthawk then I think users who used it for swaps would not have been effected.
But something worth considering in my opinion is that having this thorchain integration in Nighthawk, although the users wouldn’t have been directly effected, it’s possible that at least some Zcash community members could have decided to become LPs after being introduced to the project on an app they trust with their ZEC. So it’s possible that in that hypothetical situation some Zcash users could have lost ZEC by using it to LP inside thorchain because they thought it was a secure trustworthy project because Nighthawk who they already trust with their ZEC & the ZOMG who are ‘leaders’ in the community funded the integration….
I’m not sure if this is too much of a hypothetical stretch to be considered, but I do think that is how users tend to explore products, see an integration with another project in something they already use, then dig into that other project & potentially deploy funds….
& on the more speculative & paranoid side of things, it’s entirely possible these exploits are being committed by one or more of the anonymous insiders/devs that work on & or created thorchain…
Thanks for the feedback @decentralistdan
I will get in touch with the Thorchain devs and get a status on the critical issues and audits.