ZK-Snarks as a Service

Let’s discuss this more!


I really like the idea of focus on utility. I hope, in the long term, the utility of ZCash can speak for itself and by doing so increases the monetary value of ZCash based on its material use.

I’ve been thinking that we could use non-fungible ZSAs as pseudo cryptographic token for signing/encrypting. This might allow 3rd parties to use zcash for authentication ZSAs - Sign in with ZCash.

I’m not sure how the economics would work for raw cryptography as a service as you mentioned but I imagine by adding the unique features we can provide as a blockchain we might have something with value over other cryptographic services.

I wonder if abstracting away the signing/encryption keys allowing for things like private key recovery and transferable private keys is a service potential customers might use. This could be done with fungible and non-fungible ZSAs. @pkr like yourself I’m just spitballing ideas. Any thoughts/ideas/feedback is valuable :blush:.

Scenario 1 - Multiparty board/committee

Imagine a board of 5 members that are responsible for distribution of funds. Each of the members holds a unique non-fungible membership ZSA. Each member/ZSA has the ability to “sign” things on chain (and maybe even off-chain). It’s has been decided that a transfer of funds (on-chain or off-chain) requires at least 3 member to sign something. We also have decided that 4 of the 5 members are required to transfer a membership ZSA.

At some time in the future the board decides 1 of the 5 members has served their time and a new member should serve. Despite the member not agreeing to relieve their position they all sign the transaction of the ZSA to the new member.

Scenario 2 - Level 1 as a Service

A community of people decide their new awesome blockchain idea is should provide privacy for all. They decide L2 proof of stake is the way to go and they can do that using ZCash.

All members are distributed their share of “currency” and “staking” assets. They configure a consensus rule for the currency ZSA that only allows a currency transfer to occur if 50% of stalking value sign the transaction. Each staker node enforces the awesome blockchains consensus rules and signs the transaction if appropriate.

Scenario 3 - ZSA recovery

An asset holder decides they want to protect against the risk of losing their ZSA by provide a 2 stage recovery process. They only want someone to be able to recover their ZSA if they are able to provide a valid proof of identity check, and also respond to an email verification check. The user finds 2 seperate centralised services that offer this. The services are configured to allow transfer of ZSA if 2 of 3 parties sign the transfer (User private key holding ZSA, Email verification, Proof of Identity check). If the user were to ever lose their private key they could private a new private key to the email verification and identity check services to transfer the ZSA to.

1 Like

On the topic of L1 as a Service I can’t see why an “ETH” like cryptocurrency couldn’t be an L2 ontop of ZCash using ZSAs. Should have hyped this thread and titled it “ETH as L2 on ZCash” :rofl:.


I’m curious if the economist that was hired by the ECC will explore this topic during their current contract.

Love that idea of signing in with ZCash! I’ve built many personal web projects, and worked at decent sized tech companies on front-end auth, and the best solution by far has been Passport.js for a modern day website OAuth type login.

Some dev used it to create an Apple sign-in library, and the API is pretty clean (passport-apple - npm). I can imagine that with the Elemental (@1337bytes) components library, that ZCash could also have an integration, and I (or a website like Zecpages.com) could use that as an alternative to email registration/login.

I would also suggest looking into a partnership with Brendan Eich (the JS master) and Brave. Imagine if ZCash replaced 1 password manager and all the other password encryption plugins (or provided an API to do so like stripe provides for payments).

So basically ZSAs in this utility world (maybe this is Scenario 2) can now provide the following:

  • Login through any website (passport.js)
  • Secure payment (like stripe for websites)
  • Vote

I think the login with Zcash would be the most compelling to be honest, because that whole entire space (login w/ facebook, login with twitter, login with google, login with a pen and pencil, etc etc) is all over the place. Basically ZCash can become a sID for website auth (maybe this ties into Scenario 3) and I can just scan my web wallet or send a nonce to verify (PoS could have possibly a small verification fee here, wherein the holders (now validators for logging in to every website on web2 and now web3) receive payment through an updated token proposal change).

Re: the multiparty board/committee (Scenario 1), I’m going to abstain from giving an opinion right now, as I need some time to think it through. Governance is such a tricky topic that it should be thoughtfully managed from the start, IMO. I’ll come back to that.


Who is this? Do you have a link, by chance?

@Rucknium maybe @joshs can give more context here.

1 Like

As ZSAs have the potential to affect Zcash economics, ECC is pursuing a study of decentralized markets on the Zcash blockchain which involve multiple assets. We’ve engaged the Computational Experimental Economics Lab at George Mason University, under the direction of Professor Kevin McCabe, to assist with this study. Our overall goal is to develop an economic mechanism that is consistent with the sustainability of Zcash and has an overall positive impact on current cryptoeconomics.

Very interesting. I look forward to seeing the results of this research.


Re: Signing in with ZCash…

This is a potential first customer:

Imagine if governments adopted this (which they should theoretically if the citizens request it).

1 Like

I imagine ZCash authentication & authorisation could be done by implementing an OAuth2.0 server that communicates to ZCashD. There could be a community hosted ZCash OAuth server but I also imagine anyone could run their own namespaced instance. Might be a nice grants proposal for someone. The missing piece here is ZSAs but that shouldn’t stop a design phase to help set requirements.

  1. Defining all scenarios and use cases
  2. Define mapping for OAuth2.0 calls to ZCashD calls
  3. Define mapping new ZCashD calls to ZSAs actions
  4. Define ZSA requirements and any specific consensus rules/options
  5. Engaging community and gaining community consensus
  6. Implementing beta ZCashD APIs
  7. Implementing beta OAuth2.0 server
  8. Wrap it all up…

Should this work be done as extension of zebrad instead? Creating a rust crate is so much easier than extending zcashd. Also, this way the extension/crate does not need to care about the consensus as they are taken care by zcashd and zebrad.

Also, would not it be possible to do Zcash auth without ZSA? Probably not the transferable sign on key part, but Magic-like passwordless service on top of shielded addresses instead of Ethereum. If this proves to be possible then this can be developed with more ideas as soon as ZSAs are added to the protocol.

EDIT: I actually think this is a viable VC-funded startup now that I spend more time thinking about this topic. :sweat_smile:


Sure could do without ZSA. But I imagine a big value proposition is decentralized storage of ACLs using ZSAs. One could even argue the attack surface for Identity and Access Management is reduced by storing ACLs on an immutable chain.

Research could even be commissioned to check that claim.

1 Like

To clarify I’m not so interested in the ZCash community trying to directly profit from offering fee paying auth services. Only fees involved should be nominal ZCash (trans)action fees imo.

I’m imagining a world 5 years down the line where the value proposition for using ZCash for Identity and Access Management is so attractive that all the big name IAM providers will advertise ZCash specific integrations.

The benefit of course is the 1,000,000s of companies having to now hold ZCash to pay for ongoing provisioning of new users and ACLs etc.

1 Like

Yes, I was alluding to creating an open source extension to zebrad to enable this use case. Then, provide a SaaS product where everything is taken care of for the customers (the 1000000s of companies) with Zcash as the backend.

This is obviously a long-play and will depend on a lot of things to happen at the right time including development of Zcash.


Agree. Zebrad would be great. I’ve started bringing this all up now because the stars are kinda aligning for the perfect storm for this type of thing to become a reality. ECC already seems all in on ZSAs and recursive proofs and open to the idea of unique ZSA use cases.

I think the main advocating required at the moment is making sure ZSAs will or can easily add support for:

  1. non-fungible assets
  2. management/issuing assets; where one asset is used to issue and manage another asset
  3. asset linking, where an asset references another asset


  1. non-fungible assets can be used as long life (or short life) user/access tokens
  2. management/issuing assets can be used as a pseudo certificate authority issuing pseudo certificates
  3. asset issuing and linking can be used together to produce a pseudo signature asset (an asset that contains both an issuer and a reference to another asset)

I think these primatives are enough to allow an independent auth service to start their own independent instance by issuing new user assets and ACLs on ZCash.


ZCash can become a sID for website auth maybe this ties into Scenario 3 and I can just scan my web wallet or send a nonce to verify PoS could have possibly a small verification fee here, wherein the holders now validators for logging in to every website on web2 and now web3 receive payment through an updated token proposal change.


Access Management is so attractive that all the big name IAM providers will advertise ZCash specific integrations.The benefit of course is the 1,000,000s of companies having to now hold ZCash to pay for ongoing provisioning of new users and ACLs etc.

1 Like