Hello Zcash nation,
Vergara Technologies is submitting an application for a ZCG grant for the work of migrating the ZGo point-of-sale application from zcashd to the Zebra node. We have been working on this since the spring, we have released related enhancements to the Zenith RPC (0.10.0.0, 0.11.0.0, 0.11.1.0) and we’re on the final phase and targeting a release by the end of December.
You can read our full proposal here, looking forward to hear feedback from the community.
I support this grant, lets zGO! 
Hi @pitmutt, thanks a lot for putting this together and for continuing to maintain ZGo and Zenith over the years.
Right now, most new ZEC payment flows for merchants are naturally gravitating toward the BTCPay Server plugin, for pretty simple reasons: it’s easier to plug Zcash into an existing payment stack than to convince merchants to learn and self-host a separate point-of-sale system. We also ran into this when talked with Nym devs about “the best way to accept ZEC as a payment method”, you know.
From the committee’s perspective, ZGo is currently the only real alternative to the BTCPay plugin in the “Zcash-native payment processor” category, and migrating it from zcashd to Zebra via Zenith looks like a logical and necessary step.
To help us evaluate the grant properly, it would be helpful if you could clarify a few higher-level questions. We don’t want to simply “keep ZGo alive”; we want to understand where it can grow and how this work fits into a sustainable future of Zcash ecosystem.
Product direction
Right now ZGo feels like a strong idea with low visibility. How do you see its role going forward, especially alongside the BTCPay Server or Binance payments, for example, as popular CEX solution? What is ZGo uniquely good at, or what could it become uniquely good at, that would make it worth investing in beyond this migration?
Practical adoption
What would be the most effective steps (from your perspective) to make ZGo easier to adopt in real life? Examples might include “one-click” deployment, simpler UX for merchants, demo shops, integration guides, @ZecHub partnership, etc. We’re not asking for a marketing campaign, just an idea of how ZGo can realistically reach more users. What kind of help would you like to receive from our Community structures?
Scope and maintenance
How much future maintenance do you expect after NU7? We’re trying to understand the long-term cost of keeping ZGo running.
Milestones and cost split
You mention that work on the Zebra migration started in the spring, and you’re targeting a release by the end of December. Could you clearly separate which parts of this grant are retroactive (already completed work) and which parts are forward-looking? Would you be willing to restructure the grant into two milestones, with separate deliverables and amounts for each?
Please everyone who has ideas speak out. Thank you!
At nearly 140 k usd, it looks a rather low ROI considering that most crypto merchants would rather use Btcpayserver which already had a plugin funded for much less.
Yes, it is. But right now in X (you might have missed this) there is a discussion that we don’t need ZSA and other things anymore either.
To be honest, I’m a little shocked, but I try not to show emotion, answering myself “Okay, you don’t always know how doing right at a particular moment in time and people around you have already proven this to you more than once.” The more people, the more opinions. I hope we will go through this big circle of discussions again and come to a consensus.
However, in this case, the ROI of ZSA costs will be even lower. In general, I am already accustomed to the fact that we, like Isaac Newton, write many wonderful discoveries and put them in our desk so that other people can use them later. In the case of ZGo, this may be an alternative to the plugin for BTCPayServer if for some reason they decide to exclude us from the menu.
not sure if your analogy applies here. This is not an invention, but a commercial product to facilitate business. I don’t think diversity really matters.
I think its important to have another option for accepting shielded ZEC. Zechub has been using ZGo and we hope to continue to unless we are forced to change due to bugs or zcashd deprecation issues. Pittmutt has been very active in his help channels and that is greatly appreciated.
ZGo’s big differentiators are that we support both Sapling and Orchard ZEC, we are non-custodial (payments are not made to a ZGo wallet, they go directly to the vendor’s wallet), and that we take care of the Zcash infrastructure. The vendor doesn’t have to worry about node hosting or maintenance.
After working with brick-and-mortar vendors, and learning of the challenges of getting them out of the sunk-cost trap their current Toast/Clover/Square/Stripe setup put them in, we pivoted to create the integration to WooCommerce.
This approach was more successful but one of the things that my interaction with vendors showed is that even setting up a WooCommerce shop is, for most small vendors, too high of a technical barrier. I have approached several creators that sell online and though they admit that they’re not happy with the fees Etsy charges (and keeps raising), they use it because it’s easy. They’re not computer savvy, they make art, jewelry, etc.
The long-term vision I have for ZGo is to give that experience to a vendor, where they can create an account and have a shop in a few clicks. This ZGo-as-a-better-Etsy platform would already have Zcash built-in, and offer discounts on the fees for merchants that choose to accept ZEC. I think there’s space in the market for an app like this, especially if it can provide features that appeal to people that are moving away of the Big Tech platforms, like built-in ActivityPub support.
We need vendors. We need to identify people and businesses that are active in the community, that want to accept ZEC. We need to be able to show those vendors that there’s enough Zcashers willing to spend ZEC to make it worth their time implementing ZEC payments. I discussed an idea here.
ZGo is built in a way that we can add new integrations, if they can make API calls and receive them, we can work together to link their system.
The maintenance of the Zebra version of ZGo is something we can absorb, and we have a healthy runway for those costs.
Sure, I can break it up on the completed work and the work to be finished by the end of the year. Should I update it on Github?
My reply is in reference to this:
Being able to easily use Zcash as a vendor is a core part of the mission of unstoppable private money. Being able to use Zcash as a medium of exchange needs multiple options for both users (consumers) and vendors and I consider it very hard to predict which solution will win in the marketplace.
So while I highly respect @hanh as an engineer for all his contributions to Zcash I don’t follow his arguments here, I don’t consider it relevant for a decision that other solutions exist in this case or that it’s a commercial product. We need to drive Zcash adoption and if this helps driving it it’s fair game for me.
It’s a good sign that @dismad approves of this. Even more so that the existing ZCG committee member @artkor is engaging positively with the proposal.
My first oder of business would be talking to @artkor to get a better understanding of the historical context of this application, the existing ZGo product, and the skills and ability to deliver of @pitmutt.
Since @artkor already has all this necessary context it would be the most time efficient way for me to get that context and then I would investigate further from there.
But at this stage it’s more likely I would accept this application than reject it, but I wouldn’t make this decision without digging deeper first as described.
To comment on open grant applications as a ZCG candidate, I would lean towards approval of this mostly retroactive grant, with a month or so of work left. I agree that Zcash needs tools for vendor adoption, and ZGo seems to have community support with limited zcash native alternatives. I think it’s telling that Zechub is using it.
General Questions:
I suspect that some of the current community grant members know the answers, and would seek a discussion with them if I was on the board making this decision. Otherwise, I am favorable in approving.
I would most likely approve this grant in full and fast-track it.
This project seems to pass my three non-negotiable rules:
The requested amount seems reasonable compared to the ecosystem value. Migrating to Zebra removes the single biggest risk to ZGo’s survival after zcashd is deprecated.
Since we are near December, setting milestones do not make much sense, I would rather include a clawback in case of delays.
This is the kind of infrastructure that makes private money actually used.
We did receive a request from a new vendor. Due to the current migration to Zebra, we will work with them to implement their shop as soon as we are live on MainNet.
Zenith is not a mobile wallet, it is a desktop wallet built to run on a local Zebra node. Product Details. Zenith also has an RPC server, that allows apps to interact with the Zcash chain programmatically. We are leveraging this functionality to remove the current dependency on zcashd and use zebrad instead.
This is probably the hardest problem, a bit of a chicken-and-the-egg problem.
A vendor will only bother implementing any Zcash payment if there’s enough people that will buy from them with ZEC. It’s not worth doing if you’re only going to sell $20 every two months to one guy.
People will want to spend (and receive ZEC for payments) if they know there are multiple places where they can use ZEC. See point 1.
I detailed an idea to start this flywheel here.
Re migration to SQL, this is something that I support. PostgreSQL would be nice given the split between MySQL and MariaDB, but both are solid options, especially compared to MongoDB.
zcash-walletd also has support for both Sapling and Orchard UA receivers. I hope to work on multi-wallet support next year, which would let merchants use third-party hosting.
While I believe the more options are available for accepting payments, the better, I also feel that it’s worth moving towards a model of providing “unconditional” funding for a base amount to cover minimal essential functionality, then have unlockable milestones based on metrics such as merchant adoption or transaction volume, and funding should be at least somewhat proportional to the level of merchant interest and adoption for each solution.
The cost is somewhat high compared to the more recent BTCPayServer grants: what would make ZGo more attractive is a developer friendly API that is standardised around the zcash-walletd/Bitcoin CLI RPC with payment notification callbacks, that can easily be adopted by merchants such as Mullvad and multi-account support that can be used via a single RPC instance and Docker image. Maybe this is possible with Zenith directly? I guess the main difference would be that this is a full node wallet rather than lightwallet client.
As @artkor mentioned, it would be great to have the grant restructured into separate milestones to clarify what work is retroactive and what is yet to be completed.
If a vendor wants to write RPC calls, Zenith has a full set of RPC methods to manage a wallet programmatically.
ZGo is aimed at the vendor who can’t/doesn’t want to code a custom solution or run Zebra nodes, all they need is a mobile wallet capable of generating a Unified Viewing Key.
Is there mempool support (for updating invoice status to received)? And would it be much work to implement a tx-notify callback to avoid polling for listreceived? From what I can tell, an equivalent to get_transfer_by_txid seems to be missing. Would be nice to have a full-node wallet that can be used for BTCPayServer without the need for a lightwalletd server.
There is no mempool support on Zenith at the moment. We did implement a blockheight parameter for listreceived so users can limit the response to the last block they checked.
We welcome ideas to enhance the RPC interface of Zenith, will look into get_transfer_by_txid functionality.
I think that an e-commerce solution for small shops is great. It’s something Zcash can benefit from. Having a shop is a lot of work. You can’t ask someone who’s already working 12 hours owning a shop to actually run infrastructure, so I think Zgo actually has a strong advantage by understanding the field they are working on.
Although, to me it has a marketing an aesthetics problem to solve first. I can see that woocommerce customers do have some taste for clean designs since that’s how woocommerce advertises their product.
Taking the risk of being judged as superficial, I think that Zgo needs RENO and marketing. I honestly can’t see someone choosing a product like https://woocommerce.com/ and its aesthetics proposal to fall in love with our beloved ZGo if it’s looking like this.
I’d restructure this grant so it focuses both in the looks and in the inner workings of ZGo so it looks on the outside as well as it’s designed on its backend.
This grant is submitted mostly retroactively for the work done to migrate ZGo out of zcashd and all the work that has gone into both ZGo and the Zenith RPC server to support this migration.
A better-designed home page would be a great asset, and it gives me an idea. Maybe ZecHub, or one of its members, can redesign the website? CC: @dismad
Perhaps we can work with ZCG to fund that work, and feed the ZEC economy through it. It think it would help strengthen the community.
I hired @Minevg from Zcash Brasil for design work for my ZecDev Logo she was great to work with.
Wonderful idea, we can look into it!
