Zcash Functional UX for Private Storage and Payments

I spent this morning documenting the high level functional architecture I’d love to see and use with Zcash in support of private storage and payments. It includes a few things that many of us have discussed publicly, and a couple new ideas that I’ve been thinking about. Please note that this is conceptual and for conversation. It is not intend to be a roadmap.

Here are brief descriptions of some elements:

Zcash Vault is a for-purpose hardware device for self-custody of shielded ZEC, ZSAs and a shielded stablecoin.

The Zcash Vault software is the front-end to the hardware device (ex. Ledger Live) and robust capabilities including:

  • Issuing and redeeming ZSAs
  • A means to collateralize ZEC and ZSAs for use as cross-chain letters of credit (LoCs). Credit may be settled through direct payments or the redemption of collateralized assets. This is something I’ve explored a little bit with Tyler Spalding, the founder of Ampera and @secparam and think its feasible.
  • It is also the interface to a future PoS Zcash, supporting staking and delegation, and participation in governance.
  • I added another feature called zkID, that would allow the sender to send some encrypted identifying information and/or a proof to a counterparty for compliance. zkIDs might be stored as ZSAs.

A Key Management Service, perhaps something similar to Casa, is available as a subscription. It provides support for the setup and operation of a multi signature wallet. This service might also provide identity verification services for both key signing and recovery, as well as for optional use to prove identity questions to third parties (i.e. citizenship, etc.)

The Mobile Wallet is simply Venmo for Zcash, with the ability to engage in P2P transfers and payments.

The credit / debit card allows a user the option to engage with legacy merchants using funds or letters of credit available through the use of collateralized assets.

The Solana, Ethereum and Avalanche chains are shown as possible gateways, where the third party is accepting payments on one of these chains in the form of a stablecoin. A good UX would require that the complexity of swapping and issuing payments through stablecoins or LoCs is abstracted away.

Look forward to hearing your thoughts!

36 Likes

It’s beautiful!!

10 Likes

On reading this my New Year’s Day Hangover has fallen away like scales from Saul’s eyes on the road to Damascus!

I know you said it’s not intended as a roadmap, but with with ideas like these for zcashers to ruminate on: “where we’re going we dont need roads”

6 Likes

So “The Vault” is like a Ledger and “The Vault Software” interacts with the hardware device.

Do you have a particular base hardware in mind for the Vault itself? The biggest issue the developers like Zondax had integrating Zcash was the severely limited RAM and processing power of the Ledger, and the Trezor.

To do all those things I would imagine that a Raspberry Pi or some other open source hardware could be used?

To make it ultra secure I’m picturing some sort of process that goes:

  1. Get a Pi (specs TBD)
  2. Get a Pi camera add on
  3. Get a LCD display shield for Pi
  4. Use Zcash Vault Software (ZVS) similar to Electrum to make offline wallet on Pi.
  5. ZVS also installed on separate online device as watch only wallet (Laptop/Phone)
  6. Start transaction with online device, generate QR
  7. Scan that QR with Pi
  8. Sign transaction on Pi, display QR
  9. Scan the QR with the device
  10. Broadcast transaction with device ZVS

It’s a bit of work to make a transaction, but it would be as safe as any cold storage wallet. If vendors wanted to they could sell it as a DIY kit for Zcash?

It would be even better if we could get the guys like Jaxx onboard to integrate with existing ecosystems but based on past experiences that gets very expensive very quickly.

Overall love the ideas :ok_hand:

4 Likes

Yes.

I think this is a commercial product rather than DIY. There are three paths to get there: build, buy or white label. The hardware would be more performant than the legacy Ledger or Trezor devices, which has become more common.

6 Likes

The computation time for orchard transactions on the Ywallet ledger app is dependent on the number of inputs and also prebuilding the key. Assuming you do that and just make a normal transaction then it actually doesn’t take very long. Still pushes the hardware to the limit of its capability. I don’t know exactly what kind of guts are in it, I presume something like an ESP 32 (?).
The only issue I suppose with a pi 64 bit would be the form factor and maybe power consumption (smidge more I don’t know). Their (pi4) availabilities may be better than it was a few years ago, but I remember that was always kind of one of the issues with basing a non-hobbyist/diy design on commodity Pi hardware. I don’t personally know of any 64 bit microcontrollers in that little usb-stick-size form factor. Perhaps just* increasing the memory on the existing board could benefit the overall process.

2 Likes

can wait to see the roadmap and how the 3 orgs will work together and reprioritize spending towards achieving a common goal

the roadmap will be the key. i really hope we take a hard turn away from zec as a fiat alternative; we spend quite a bit on non core extraneous grants and projects and this money can be refocused on a few engines that can power Zcash forward. Most importantly, the price of zec should/will increase with a viable roadmap.

1 Like

I would just use a secondhand phone.

Personally, I don’t think this is a good usage of engineering resources. The Vault and the Vault Software are essentially a cold wallet under a different name. There are companies working on it full-time. Considering the financial situation of the ECC, it is far down the priority list IMO. Then again, there are so many items on this roadmap.

“The Person Who Chases Two Rabbits Catches Neither”. This roadmap has half a dozen rabbits.

5 Likes

Hi Hanh,

Thank you for the feedback!

As I mentioned, it’s not a roadmap. It’s the capability I would like to see. In order to achieve big things, you must set out to do big things. It won’t happen accidentally, haphazardly or on the cheap. It will happen because we have clarity on a common goal and the will to make it happen.

I don’t expect that ECC will build all these things. We’re only part of the much larger community. ECC will have to prioritize our time based on where we can have the most significant impact toward driving adoption. If we chose to go after things that our beyond our current budget, we’ll seek additional funding sources. Nothing is off the table.

I hope that ZCG will focus funding on things that align, if they see potential. But that’s not up to me. I believe the Foundation is doing that now with foundational pieces to this puzzle that will allow us to run, not walk.

As we’ve experienced with Trezor, Ledger and others, we cannot trust our fate to third parties with misaligned motives. It’s up to us to build and drive the future we want to see.

I came back to go big with a mandate to drive adoption by delivering products. It’s my intent with ECC’s Zeboot to align and prioritize those efforts that will get us there most expeditiously. We cannot continue to build great cryptography that is not broadly useful. It’s time to take off the training wheels and build products people need and love.

18 Likes

Hear! Hear!

6 Likes

Almost every project running in production as far as token as a service or wallet as a service or blockchain as a service has an integration with fire blocks in the back end. very similar architecture pattern to what you describe with a mpc for the vault portion to offer recovery if clients want They also support zcash . They are b2c and b2b focused not really p2p for the average user

3 Likes

Looks great and sounds like exactly what Zcash needs, a common vision and blueprint across the entire community and all three organisations.

I think we should double down and go all in on three major features/unique selling points/categories/umbrellas. I don’t know what this looks like, but for some reason I just remember when Steve Jobs got on stage at MacWorld back in 2007 and introduced the iPhone by repeatedly saying iPod, Phone, Internet, iPod, phone, internet and the crowd started going crazy because they got it straight away.

Zcash by way of what Josh has presented here needs it’s own “iPod, Phone, internet”. Most importantly, the three features/unique selling points/categories/umbrellas need to be from the perspective of what the user wants (that’s not familiar with crypto) & using familiar terminology to them; maybe something like Vault, Payments, Earn or whatever but you get my point :slight_smile:

3 Likes

Generally I’ve been bearish on ZSA because of measurable lack of demand from serious issuers like stable coins and the lack of an on chain dex.

Ordinals/ BRC-20 have demonstrated a robust market for speculative assets in absence of the enabling infrastructure.

It’s unlikely to be a home run but would be positive momentum

4 Likes

Yeah, but it needs Developers.

Developers.

Developers.

Developers!

image

3 Likes

Hey Josh, thanks for the thoughts here! I appreciate you looking forward a bit.

I have some questions/comments about stablecoins and the avalanche, solana and ethereum chains… everyone should chime in as well.

Stablecoins

  • What type of viewing permissions would asset issuers be able to have when issuing stablecoins on Zcash? E.g. Circle likely would need certain viewing permissions!

  • How is USDC on ethereum, solana and avalanche relevant to Zcash?

  • Have you considered something like RAI?

  • Is t-addr deprecation a part of this thesis?

  • zkID - could this lead to a slippery slope where users have to submit zkID or their transactions aren’t sequenced? Seems a bit like proof-of-innocence (PoI). PoI isn’t necessarily bad (although not ideal), but curious if you’ve thought about potential consequences here!

Other cross-chain stuff

  • How is the ZEC token valuable or useful to other networks? It’s not securing any cross-chain protocols, and the market has shown us that ZEC is not a desired monetary asset. What are the plans to use ZEC in some form or fashion, in a cross-chain way, other than just being a wrapped synthetic? Maybe an answer here ties together the “zStable” in the avalanche and solana diagrams.

  • Would the bridge be to Ethereum, or to its Layer 2s where the majority of activity is moving?

  • Someone texted me this idea when discussing my own rollup idea. This could fit in nicely with your line of thinking!

Lmk! The cosmos, sovereign L1 thesis could fit in nicely here.

1 Like

Thanks for the all the good questions. Please keep in mind, this is a high level functional architecture, not a detailed design. While each element is achievable, there is a lot complexity embedded in here. I don’t presume to know all the implementation details.

It’s been well over a year since I worked with Circle on this. At the time, they expressed interest but only if it was possible to whitelist addresses and freeze funds due to regulatory rules. I’m confident that supply auditability would be a concern for an issuer of a shielded stable.

The idea here is that you would be able to store shielded assets on Zcash, and then either swap or collateralize them for USDC payments on other chains. In this case, your USDC transaction is public on that chain, but your asset holdings are not. It allows ZEC and ZSA holders the ability to spend in the case where USDC is the preferred method.

No. But, I’m not trying to be specific here. USDC is illustrative.

Not explicitly, but I think this would allow for that to happen gracefully, with cross-chain swaps being the means to support transparent payments.

It’s admittedly a pretty hand wavy idea right now. I see it as something totally optional for the sovereign user, but possible to support regulated scenarios where they user wants to participate, i.e. and exchange wanting to verify source of funds. Or more abstractly, where the acceptor of a credit is able to verify that some information is true before accepting payment, i.e. the payer is anon but verified to be over 18.

That wasn’t a design goal. My design goal was to scratch my itch - a means to securely and privately store and use my wealth.

Arguably, the majority of activity is moving to Solana. :wink: The intent here is to be cross-chain supporting but agnostic.

Thanks Ian! I hope that helps clarity.

2 Likes

Thanks for the responses! That cleared a few things up.

I like this idea!

Solana’s cool! just curious about how bridging to Ethereum would work. Liquidity fragmentation might become an issue, so an interesting engineering problem is to be solved here.

1 Like

Happy New Year @joshs! All these ideas are really exciting and refreshing!

Z-Vault: I think it’s very important.

while ago, when it came to the Ledger Support grant for Ywallet I posted this warning about the importance of securing the entrance of the grantee through the Ledger Walled Garden gates. Also flagged this as a big issue (as it ended up being), and also proposed a (much more idealist and idilic) idea of an open HW wallet for ZEC that’s not under Ledger or Trezor’s domain.

I propose that ZF and ZCG should find and foster Open Hardware and open source software hardware wallets that decentralize and offer a free (as in freedom) alternative to hardware wallets.

Why secure self-custody is so important?

  • it’s the only was crypto users can be more certain being capable of using and accessing their funds how they want and when they want.
  • Paper wallets, iron wallets, time capsules, etc have one weakness in common: they can be breached easily by those who can gain access to them.

Why supporting shielded custodial services is also very important?

  • When moving to a custodian service, there will be information leaking. Shielded support is the only way custody can be delegated minimizing info leaks.
  • Having your funds in custody at home makes you sovereign, but also can put you in danger. E.g: receiving a package from a HW manufacturer at home seems leaks the fact that you hold crypto assets and where to find you.
  • Sovereign custody sounds cool, but it’s not suitable for every user.
  • Global Real-Estate high prices are making people share households with people which can’t be trusted with one’s earnings, savings and investments.
  • Or worse, many places where crypto would be most suitable for have living conditions that are far from ideal. Living conditions offer little to no privacy: individuals share rooms, etc. Can you have sovereign custody if you can’t be sure someone isn’t sleeping in your bed while you are out?
  • There could be situations where you wouldn’t want to have sole and sovereign custody of funds an need to have a secure way to share funds or have an easy way to have others inherit your funds.
  • Or the opposite, you want to have secure custody of funds and yet be able to avoid close members of your household accessing them because of many reasons.

Additional thoughts, reflections and ideas in support of making this Functional UX proposal a success

Background

“Build it and they’ll come” did not appear to work as much for Zcash.

New paradigm: Build it and they’ll come in such a way you can go everywhere and have the friends made along the way come over, as well as strangers walking in.

Trolls aside, there is a lot of respect for ZEC in the crypto space. The interest in its technology is such, that given the perceived impossibility of bringing ZEC over, people would just find ways to have its zero-knowledge tech where they needed it.

We also lived our own “Henry Ford dilemma”: If I had asked what people wanted they would have told me faster MPC ceremonies (instead of faster horses), and we built technology that will eventually make Zkp-MPC ceremonies a thing of the past.

Yet, after all that effort (shared and made by developers and Zodlers) “they didn’t come” as much as we would have liked.

The idea that Josh is bringing up is huge! It will require a lot of effort, Zcash ecosystem and development community will have to grow it capacity, headcount and throughput.

Maybe it’s time to think of the cost of coming over to Zcash, and how to make that less of a problem so that we can be more competitive

I have the impression that Zcash sometimes feels as a wedding in the Amalfi Coast. Oh, those magical moments! Aren’t they a dream? wouldn’t it be amazing to be part of something like that? And yet, if by any chance you get an invitation (and you are not rich), you’ll open up your household budget excel spreadsheet and start sweating! And after a reality check, you’d start thinking of elegant ways to excuse yourself of such an economic burden of an event.

Brainstorming dump

Lowering the cost for Users to come ever to Zcash

If we want to make ZEC be in the hands of everyone, we will have to open pathways work in both directions, allowing ZEC to flow in and out and also making an ecosystem where people who come by, build with the tools they already know, and if they don’t know any, those tools need to be useful somewhere else.

The balance of choosing ZEC over other platforms should be net positive. Even if that person ends up leaving. That will lower the perceived risk of diving into Zcash.

For developers:
“if I choose to work in the Zcash Ecosystem, and it happens that I don’t end up liking it, I would have learned something useful that is valuable in general”.

For users:
If I chose ZEC as my first crypto, the things I learned there would serve me well even if I decided to move on to other coins.

Possible ways to connect ZEC to the rest of the world:

  • maintain the current CEX support and consider building towards expanding its shielded outreach.
  • Building Bridges: Bridge ZEC to other ecosystems so that it’s not necessary to sell your ZEC. the ZAVAX bridge is an excellent example of this.
  • Go an extra mile: Build ZEC subnets on the other side of the bridges
  • Making ZEC modular and ubiquitous like Ian has proposed
  • Decentralized Exchange support to lower the impact of CEX policies on the ZEC ecosystem.

Lowering the Cost of coming over to Zcash for Developers

Mindset shift: ZEC is super special in terms of privacy. That doesn’t mean it needs its own special everything. Study what others have done and do what worked best for those, measure and iterate. If it actually is the case that it needs that special something, let’s make it so that others don’t have to care unless they want to.

Ideas to lower this cost:

  • Improve developer experience with comprehensive, well structured documentation and Developer Relations
  • change “definition of done” for our tooling: it’s not done until someone “from outside” can read the instructions and use it without pinging the developers directly.
  • Allow ourselves to “Stand in the shoulders of (other) giants”.
    • Zcash has been recognized for advancing the cryptography space decades in a matter of months. In that sense many other platforms have used and benefited from our breakthroughs. Let ourselves do the same with those aspects that others have excelled at and we haven’t.
    • Only innovate on what is completely new has never been done before. For all the rest, prioritize general purpose tools and languages that have a wider audience
    • Reduce the amount of “wheel re-invention” by adopting “industry standards” or “industry conventions” even though it needs more work upfront from us because what’s used by many does not suit or very own requirements.

Potential Risks of the OP’s proposal

  • Engineering risk: This proposal could be to overly ambitious for the available resources and suffer of a Big Bang approach problem.
  • Political/sand table risk: the proposal appears to require buy-in from every single actor of the current ecosystem and seems “too holistic” with little wiggle room for discrepancies.
  • Centralization Risk: The proposal might increase the perception of Zcash being “too centralized”.
  • Bikeshedding risk: If not structured properly, it could require too much “background/backend” work until it makes real positive impact for users
  • Perception of High Risk: It may be perceived as “the last dance” or “all in” kind of move.
  • Perception of High Risk: The proposal has many moving parts and actors. Many of this actores are yet to be known.
  • Time To Market: The proposal TTM appears to be too far ahead as a whole and could be outperformed by competitors.

Note for people not familiarized with Software Engineering:

There are no risk-free projects. Risk Analysis is a discipline within project management. There are many ways the mentioned risks can be mitigated. Risks are not be feared neither to be hidden under the rug. It’s important to identify them as early as possible and work towards minimizing the probabilities of them occurring. Proper risk analysis and mitigation are sometimes seen as things that foster “detractors” and “kills inspiration”, but in reality it is an investment in maximizing the probability of success by lowering the chances of failure.

Conclusions

Zcash needs to redefine itself and find its place in the present and the future.
It’s really good to be discussing a paths forward!

3 Likes

@joshs After reviewing your architecture outline, is this diagram correct in looking at this from a layering perspective?

1 Like

Good stuff I been saying the same thing. About ZEC myself I think on the monetary side polka swap would be great for Zcash. On the other hand, Shade protocol would be excellent it has all the tools a Zec investor would need. Stash.io for NFTs making ZEC valuable should not be hard if we secure compatible chains.

1 Like