It does appear LP providers have been restored, which I’m happy to see. You did add an edit about that while I was working on my response, hence the omission in my reply. Thanks for the update and confirmation.
Sorry but this statement can be misleading as users are keen on Zcash - Thorchain integration, but not necessarily this particular proposal.
I would want to wait Thorchain to be running without problems for a while. Perhaps, new @ZcashGrants board can then decide whether or not to approve this grant. A few months is not that long while folks are focusing on NU5.
The risk/reward of funding Thorchain integration looks good enough now that I’d like to see zomg go ahead and commit to funding. Not necessarily this grant, but commit to funding a Thorchain integration in general.
If this particular cost estimate seems high they could put out a formal request for proposals and let developers bid. But I also think they should prioritize getting it done quickly and competently vs too much worry about costs in this case.
ZOMG is (as of last meeting) undecided on this proposal, there was not enough consensus to approve.
[Speaking personally now, not for ZOMG] My biggest concern with this proposal is the cost. If you want to push for a proper vote as-is for tomorrows ZOMG meeting I will be a no.
Interestingly, THORSwap mentioned Zcash integration just last night:
That tweet gave the impression that they may already have someone working on it, so I jumped into thier Discord to learn more:
At the end of the day, I too believe that Thorchain->Zcash is a project worth funding. Perhaps a way to move forward, as @aristarchus mentioned is to begin a RFP process and see what other teams come up with.
Just checked in with the Thorchain devs if they are going to allocate any resources for the Zcash <> Thorchain Integration or if the integration will be done by developers from the Zcash Community ?
“Every chain integration has been driven by the chain’s community, not the core devs. That would spread the team far too thin.” is the answer we got.
I also reached out to the Thorchain developers. They did confirm the standing Bifrost would be mostly usable, just requiring the tweaks mentioned before in this thread (addresses). The only part which borders on unusable is the BTC library they use. That will have a different TX serialization and will need patching accordingly.
- Serialization, which matters for signing TXs
- Deserialization, in order to be able to work with existing TXs, unless the node offers a usable JSON encoding
- Address handling if you wanted to tackle UAs now
- Misc RPC changes to account for any version differences
The first is tested easily enough, especially since you never need to work with shielded elements. You just need to prove it works by submitting a TX to the network., Deserialization is trickier, yet if you ignore shielded elements due to their irrelevance, making the lib strictly transparent ZEC, I’d hope it isn’t too difficult (especially if you can just stop parsing TXs in the middle, accepting everything after a certain point to be irrelevant, coming back from the tail as needed if needed). Testing can be cross comparing parsed results against JSON from any block explorer which will confirm accuracy.
UAs is another discussion but it doesn’t have to be done now. This library will already need to be updated with NU5 to serialize the orchard fields (with empty data) I believe, so there’s no need to do it here and now.
If you modify the btcsuite set of libs to hook into GitHub - iqoption/zecutil: Zcash Golang Signer, that could also reduce development time, though it may not be the best solution.
zips/sapling.pdf at main · zcash/zips · GitHub page 86 has the specifics on serialization. It does appear any transparent-only parser can simply stop after lock time.
I may actually be willing to work on this library, if my schedule allows, and you’d be willing to discuss it. With this info at light, I’d hope the development work to be greatly reduced, along with testing since instead of a new Bifrost being tested, it’s the standing BTC Bifrost which has already been extensively tested and reviewed.
Whats your opinion of Waves DEX?
They have Zcash/USDN , if we showed more support for their new and soon to launch (november 2) WX project, they might add a ZEC/USDN pair or maybe if we ask nicely a ZEC/Waves pair which I would enjoy.
To take part in the early birds program, you need to provide liquidity to any liquidity pool. Currently, the following pools are available:
Shortly, more and more pools will be added, which you will choose by voting with your gWX tokens.
Among early liquidity providers, we will distribute 1,000,000 $WX tokens, which will be gradually unlocked over a one-year period following the completion of the early-bird program. The early-bird program begins on October 21, 2021 and will run for 5 weeks, until November 25, 2021 . Thus, 1 000 000 $WX will be distributed among those who will provide liquidity to any pool between October 21 and November 25, 2021.
Waves WX Early Bird Program Info: WX Token Early Birds Program. $WX is a governance token of… | by Waves.Exchange | Waves Exchange | Oct, 2021 | Medium
I’m pretty sure they’re centralized custody, decentralized order placement and matching. So basically wrapped tokens, except you don’t even get a multisig which is RenVM’s whole product and why renZEC is meaningful. It’s good to know they exist, yet not relevant to this topic as they’re not close to what’s being discussed. I especially don’t think the promotion of another token is relevant or beneficial (bolded dates on how to participate in their airdrop/incentive program), but hey, I’m not a mod here. I also haven’t looked into them in depth and could be wrong.
EDIT: I did do further research and stand by that assumption. Their docs are minimalistic and I see nothing commenting multisig custody. The existence of two services named Waves DEX is also annoying…
I see them as an ally as you mentioned is what brought this comment to mind, they offer Z-address and have since the start.
Considering FROST for ZEC hasn’t been published, this effectively confirms they have centralized custody.
As an update, Thorchain is already partially down once again. There’s is some undisclosed issue at this time which caused the admins to disable liquidity providing (deposits and withdrawals) while they resolve it, saying they’ll have to manually set database values in a hard fork (network upgrade) to correct it. This is why I advocated for waiting to see how Thorchain handles itself post-relaunch. If you say it had months of development and review, that’s all fine and dandy, yet within just a few days of being fully available once again there’s already a new major issue (hopefully resolved within the next 24 hours).
Does this mean 250k ask for this grant might be too much? Even Thorchain thinks so.
is the tweet. You’re missing a number
It’s basically what I said earlier when I confirmed most of their work should be reusable with them. I’ve been saying for a while this grant is mispriced and this fact seems to further say so, as the grant was priced as if it needed wholly original code.
As one other note, I believe LP providing is back, yet a feature they offer (ILP) is not and won’t be until the hard fork, presumably with the aforementioned manually set DB values (manually set in code, not by nodes) but I’m not entirely sure there.
this is news to us:
THORChain treasury is happy to support and seed the liquidity.
@aiyadt How does the news that you will not need to provide liquidity for Zcash affect the scope of work/cost of your proposal?
Also, THORchain mentions:
However, it needs a ZCash dev to monitor and provide through-life support.
This section of your proposal says ongoing (through-life) support is not included, is that correct?
Hot off the presses! Erik Voorhees just said he would match a donation to a dev to integrate Zcash and THORChain!
Great initiative but I’m pretty sure Erik does not know what this particular grant asks for.
Maybe a ZOMG RCP for Thorchain integration instead? @ZcashGrants
Some ideas of what to include:
- Milestone 1: Thorchain integration works which include all the things mentioned by Thorchain devs. Most of the code already exists for UTXO-based chains.
- Milestone 2: Deployment of such works and early period monitoring.
- Milestone 3: Commitment for 1 year support for Zcash-Thorchain integration. The recipient can be paid for the works involved in this stage. But commitment of doing such work would come as a bonus one year after Zcash-Thorchain integrations are running.
The Liquidity Providers are ready and the following quoted point was made earlier. The cost of the proposal is the estimate provided by the developers who will be delivering end-to-end coding, deployment and post-prod maintenance. Thorchain integration is not a one-off development-delivery task and I do not agree with @kayabaNerve’s estimates and cost cutting measures.
This has been the primary point of the team, maybe not emphasized enough, but post-prod support and maintenance is presumed to be handled by the devs who will be working on this integration. I will have the grant updated to bundle 1 yr of active support.
This section applies to ongoing automation & maintenance of Zcashd nodes within Thorchain framework which are specific changes that are taken care by TC devs.
We have already been in touch with Thorchain developers and have started work on this since many months because of how passionate we are to the Zcash community and Zcash eco-system. We need to deliver this integration carefully, which will most likely be the first live cross-chain project for Zcash.
Now the burdens of costs are coming down as other people from outside the eco-system are ready to donate funds. How soon can the Zcash community deliver their part?
P.S. I’m loving how the crypto ecosystem is starting to demand from Zcash, let’s deliver!
I support such RCP.
Having other teams pitch in is a good test of the strength of the zcash developer community.
Does that mean if Eric is serious about his matching funds offer you would accept ZOMG funding at 50% of the current grant request amount?