I’ve always been a big fan of Zcash and I still believe it’s the best privacy coin. However, I decided this weekend to try spending some ZEC using the SPEDN app. I wanted to see what the experience would be like from a users perspective, and it wasn’t that great.
I downloaded the Nighthawk wallet and the scanning painfully took forever… so long that I quit the app.
I then decided to download and try the Zecwallet Lite. It loaded quickly and thought “Awesome!” so I sent some ZEC over. Although ZEC was priced at 37.60, it was valued at $54.00 on the Zecwallet Lite app.
I finally installed SPEDN app. Wow… only 26 stores where I can spend Zcash at? I’m so spoiled. Have you looked at how many stores are in the DashDirect app? I didn’t until I downloaded it to compare, you might want to do the same.
Why can’t we have (build) something like DashDirect instead of using SPEDN? Who cares how private Zcash is if you cant spend it or have practical applications to use it.
People label Dash a privacy coin, but it is way weak when compared to Zcash. But at least you can do something with it, at least they have practical applications for people to download and easily get up and running. Is anyone surprised ZEC is struggling to hit $40.00?
It doesn’t matter if ZEC is the best privacy coin if it doesn’t get mass adoption like Dash will probably get through their real world applications and ease of use, it will just get left behind. Maybe admired and used by hobbyists.
But don’t get me wrong Zcash will be great if you want to eat Chipotle everyday. I’m not trying to be mean…but where are we going with this?
A gift card store platform in the lines of Bitrefill/DashDirect that accepts Zcash would be great! Not sure that Flexa Network is really used outside of America.
Generally there’ll be a markup in buying gift cards with crypto, when there is a discount and you can save money by paying for a gift card with crypto, most likely the app is engaged in a grey market (where users are selling the gift cards for crypto) which could be a target for regulators and stores; gift cards could be invalidated if it turns out that they’re bought with stolen funds. Gift card marketplaces like G2A can be problematic and would require good legal knowledge to go ahead with this.
Maybe this is something that could be built on top of Elemental Pay and some kind of gift card API which would handle the distribution/validation of gift cards.
I don’t know, it seems pretty straight forward with Dash. Check out the website, they list all the applications/services they have. I’m not a Zcash hater, I sunk (no pun intended) about $6,000.00 into it. But after experimenting and exploring Dash. I’m thinking of moving on. I will just HODL the ZECs that I do have.
I generally agree with the sentiment and I think asking where we are going is an important topic for the community to talk about.
So far we’ve laid out a solid technical foundation—Zebra is going to be a great improvement over the monstrous zcashd codebase that will speed up development and Orchard is a trustless payment protocol that’s quite adaptable and performant. These are great things, but we’ve paid a huge opportunity cost for protocol design and development that (in my view) came at the expense of good “product” outcomes. Grants have filled in some of the gaps, but a lot of the basics we’ll need before we can expect people to build on and use Zcash’s privacy aren’t quite there.
What I would like to see is more alignment across the community around a product suite that we can all contribute to and start to center more of the heavy-lift development around (rather than vice-versa).
Thank you for your comments, I share the same feelings/thoughts. I think Zcash is great technology, it just needs to finally leave the harbor and set sail. I think that will come once/if applications ever get developed to use it. Maybe too many academic types are involved.
Zcash released 2016
Dash released 2014
Looking at this infographic you can see how much of a leap Dash has. It looks like they just didn’t focus on the coin, but also the commercial aspects of it. Again, I’m not bashing Zcash, I’m just having a WTF moment.
Zcash is the smartest person in the room but wearing the cheapest suit.
To expand on this a little more, here are some goals I’d like to see Zcash hit over the next few years:
Crypto-unfamiliar web developers can add code to accept Zcash payments in their websites in no more than double the time it takes them to integrate PayPal.
A typical person can get up-and-running with a desktop wallet and mobile wallet within 5 minutes of visiting https://z.cash/.
Metamask-style browser-extension wallets exist, giving websites an easy-to-use JavaScript API that lets them build novel products on top of Zcash.
Zcash is adopted as the de facto choice within a niche community that’s historically struggled with censorship by established payment processors or that has a need for privacy that those payment processors can’t meet.
I could add more to this list, but I think these are the most important ones. IMO, the key to wider adoption is building something that’s a joy to work with and inspires innovators to build new products. None of us can predict how Zcash will be used or where it will be needed most, and I think the best way to find out is to make it easy for innovators to build things and test their ideas.
Usable libraries are key—if developers have to wrangle with internals of the Zcash protocol, needing to know anything deeper than the high-level abstractions they expect and want to work with, then our libraries are too low-level. We can test how good we’re doing by watching developers work with PayPal and then Zcash and then fix the roadblocks they run into.
Usability includes performance. If our libraries are too slow, innovators will turn to less-private alternatives. We might have to make some privacy trade-offs to keep Zcash in competition with centralized payment processors, but this is fine as long as we’re making privacy gains and users consent.
To reach the usability standards I’m imagining, we’ll have to work out our product goals first (library designs, targets for performance, targets for developer-time-to-integrate) and change the underlying protocol to meet those goals.
A big challenge in all of this is making Fiat↔ZEC on/off ramps accessible to everyone who wants to use Zcash. IMO, the best way to do this is to demonstrate a socially-good need for Zcash’s privacy and censorship-resistance, as I suggest in item (4) above. When it’s undeniable that Zcash is doing good for humanity, we’ll have a stronger argument against regulatory fears and have broader demand for Zcash support.
I have some ideas for (4), but I’d like to hear what ideas our community has first!
This is live in ZGo, if you use WooCommerce for your e-commerce shop.
Agree completely. I can’t go to a vendor and try to convince them to try to accept ZEC through ZGo, if when they ask “how many people will pay with it?”, I can’t give a good answer.
Likewise, I can’t convince a normie to try to use ZEC for purchases if when they ask “where can I use it?”, I can’t give a good answer.
Having a whole community jump in would bring both sides of the equation into ZEC at the same time.
Yes—I think Zcash has been coasting on the wave of speculative crypto investors, which has been great because it has been rewarding us for developing such solid technical fundamentals, but I think it’s time for us to look past the trends of the crypto world and start demonstrably solving real-world problems. Compared to every other transparent-ledger project, we’re in a unique position to be able to do so.
I’m working towards this with Elemental Pay. My goal is to somewhat replicate PayPal/Stripe front-end and back-end APIs, but for Zcash, including IPN style webhooks (most likely loosely based off Stripe Webhook API). There’ll be tradeoffs that need to be made in terms of ease-of-use, security and custody; for example if a merchant will link a mobile wallet (this will make automatic currency conversions via an exchange harder though and make them more susceptible to price volatility). Am also keen on the idea of focusing on GraphQL APIs to increase developer adoption (especially with those familiar with React.js).
For now, I feel that having an ecosystem around mobile/desktop wallet SDKs (ideally compatible with ecosystems like React Native) that can integrate features like memo extensions/protocols and encryptmessage together with decryptmessage would be a step in the right direction. For example, being able to scan a QR code on a website with your Zcash wallet to login with your Zcash address would be great.
I feel that having TypeScript and React Native libraries would be great for increasing developer adoption; need to attract UI/UX designers too.
I think that the best strategy is to help a (physical/digital) merchant support payment with other cryptocurrencies like Bitcoin, Bitcoin Cash and Ethereum additionally to Zcash, then have some kind of UX that educates users about the privacy choices they’re making (i.e. displaying a shield and animations when choosing Zcash). I feel that it’s easier to approach a merchant and ask them about accepting cryptocurrency in general rather than just Zcash; if the merchant has accepted crypto in the past, they most likely have already dealt with different customers trying to convince them about what coin/token they should focus on primarily and convince other customers to use. Need to handle this delicately. A BTCPayServer compatible backend integration would be a good starting point I feel.
When approaching a merchant about accepting cryptocurrency, they’ll generally expect to be able to accept Bitcoin/Bitcoin Cash as they’ve probably already had customers ask them about accepting them and they need to justify the amount of time and employee onboarding of setting up a new Point of Sale process and accept coins that their customers are most likely to already have.
I think every Zcon/Zcon Voices should have some sort of vendor fair, where vendors can apply to set up if they agree to only trade with ZEC for the day. The vendors that want to participate can learn how to get a wallet, how to use it, etc. They would also get the conference’s participants as likely customers. I think this could also help these events plant a seed in each location that should endure after the conference.
I live in Minnesota and last year, the VeeCon NFT conference happened here. It was a huge event, booked the entire Vikings stadium. There was little benefit to the local community (crypto or normie) left behind.
I think how the Zcash community engages these other communities can have a far more lasting impact than burning huge amounts of cash on venues and parties and hype.
This sounds like a great ideia.
Related to this topic, I have a project for this year of building a snack machine to be showcased in crypto events (in Brazil). The machine will only accept Zcash as payment.
Oh . I like GraphQL . I see your point though, initially I was going to use GraphQL as a first party API, but I realised that it’s code smell and abandoned it; am just wrapping Flask CRUD REST APIs in GraphQL now and will abstract the logic out into an adapter/repository layer to offer the choice between REST and GraphQL. GraphQL is nicer to work with in a React app when it comes to cache normalising, etc imo; you also get code-generated types too. There’s a lot of usage of frameworks like Apollo, Relay, etc.
For developer use though I agree, I’ll abstract out GraphQL and make it optional and offer REST APIs as an alternative.
The cold reality of commerce via Zcash is that it assumes merchants would like to be on the receiving end of ZEC in the transaction. As a potential merchant, it only takes 1 minute to look into the history of ZEC to understand that it is value subtractive. At this point the merchant must be a Zcash true believer, or they’ve got to be willing to take on the tax complexity of instantly converting ZEC received into paper currency. The odds of growing a merchant base under those conditions is currently unfeasible, so I would posit that one or both of the above need resolved prior to the Zcash community making a full push to onboard more merchants.
The pitch to merchants for Bitcoin, Ethereum, Dogecoin, or Litecoin (to name a few of the most popular cryptocurrencies) is that all of those coins are demonstrated as value additive over time, which allows merchants to accept them in transactions and then leave them untouched for year(s) on end without suffering purchasing power (value) loss.
I think having automatic forwarding to an exchange either immediately or daily would be good (might need to calculate the tax difference for price fluctuation), with an API integration. I’ve encountered merchants that have accepted crypto in the past but stopped because they lost a lot of money on a price collapse and convincing them to accept any crypto again will be difficult; expecting merchants to HODL mid/long-term will severely limit adoption in my opinion – maybe they could HODL a percentage though and cash out say 80% of the transaction value to fiat.
As far as I understand, one potential option would be for a physical merchant to treat each crypto payment as a cash register payment and put their own cash in the register and accepting the crypto in their own wallet, effectively buying the crypto from the customer as a personal transaction; this wouldn’t scale well when it comes to onboarding multiple employees with this process unless some tipping incentive is introduced.
. I like GraphQL 
. I see your point though, initially I was going to use GraphQL as a first party API, but I realised that it’s code smell and abandoned it; am just wrapping Flask CRUD REST APIs in GraphQL now and will abstract the logic out into an adapter/repository layer to offer the choice between REST and GraphQL. GraphQL is nicer to work with in a React app when it comes to cache normalising, etc imo; you also get code-generated types too. There’s a lot of usage of frameworks like Apollo, Relay, etc.