Zcash Thorchain Integration Grant

My ‘inner geek’ says “yeah, this sounds cool”…but I wonder just how useful (or used) this would be? Its not something I would use but that’s just my humble opinion.

Just because we can doesn’t mean we should, its a lot of $$ that could be used elsewhere.

5 Likes

That’s an good question @ChileBob

My initial review of Thorchain, the LP incentives & inter-blockchain swaps was that it would be first be a strong vehicle to onboard new users from the DEX ecosystem to the Zcash network by using native coins on Zcash blockchain VS token based system limited on Ethereum that does result in ZEC token exposure but adds primary on-chain value to ETH network only.

Then, we might start seeing existing Zcash users test & access the decentralized native swaps VS going via centralized swap providers like https://stealthex.io or SideShift.ai - No Sign-Up Crypto Exchange

Overall, I see the result of this implementation demonstrate Zcash expanding to new blockchains and making it easy for the larger cryptocurrency economy to access privacy oriented Zcash while reducing reliance on centralized exchanges. And personally, I think the budget of ~$250k of community funds will go a long way once the implementation is complete. Now it’s up to @ZcashGrants to decide if they see value in this proposal.

1 Like

Right, just want to make sure as I didn’t remember bringing it up :grinning_face_with_smiling_eyes:

So, Thorchain has their own internal incentive system where they control the RUNE inflation to attract more node runners on main-net, I heard that running a public node is very profitable at this moment, but it takes around ~$2.5M in RUNE just to get started.

The work from this grant will only touch main-net in the deployment phase when we interact with our partners who are node runners.

I agree that the usefulness is questionable at the 200k + price.

We are talking about 9M trading volume and yearly. It’s not a very useful metric but even so, this is tiny.

If there is interest, I’d suggest considering several bids and picking the best team at the best price. There doesn’t seem to be any urgency anyway.

2 Likes

Would love to see another similar proposal. Competition is good for Zcash.

I think Nighthawk team needs to deliver their funded projects first before adding a new major grant like this one.

3 Likes

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.

3 Likes

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.

2 Likes

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:

  1. thord - this is a daemon that runs the THORChain chain itself

  2. thor-api - this daemon runs an HTTP server, that gives a RESTful API to the chain

  3. 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).

  4. thor-gateway : THORNode gateway proxy to get a single IP address for multiple deployments

  5. 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.

  6. 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.

2 Likes

An in-depth discussion on What is Thorchain? and How it works via Clubhouse

3 Likes

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:

  1. It allows Zcash holders to earn yield on their assets and creates new markets for lending/borrowing.
  2. It creates a global pool of liquidity for companies to easily build future services on. For example, once Zcash is supported it will be trivial to add Zcash support to all native Thorchain dapps, other products like ShapeShift, which provide a Thorchain front-end, and even apps like Unstoppable can add Thorchain support so you can swap directly between Zcash, BTC, ETH, Tether, etc,. in a permission-less and non-custodial wallet. You probably won’t even know you’re using Thorchain in the back-end!
  3. It uses native Zcash, so your ZEC never has to leave the Zcash blockchain.

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.

10 Likes

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.

6 Likes

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.

2 Likes

… 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).

1 Like

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.

2 Likes

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).

2 Likes

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.

5 Likes

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.

1 Like