Let's bring stablecoins to ZSAs!

[vivek]

Hello Zcash community,

We at QEDIT [1] are excited to share our plans for 2024, to help you all use the shiny-new ZSA capability to the maximum extent.

When we asked the community and devs which features ZSA should include, we identified the Asset Swap functionality [2], and the need for compatibility with regulated crypto exchanges to face the increased regulatory pressure on cryptocurrencies.

So, our roadmap for 2024 includes exchange compatibility, more user control, and a big focus on stablecoins!

Stablecoins are the heart of DeFi

Stablecoins have the potential to boost adoption of the parent network they are issued on. They allow users to own digital assets but keep the stability of the underlying fiat currency used in everyday transactions. That’s why stablecoins are the cornerstone of DeFi today.

Stablecoins on ZSA would be particularly useful, thanks to the increased confidentiality of transactions.

QEDIT is active in the stablecoin space. While working on ZSA, we’ve been approached by teams asking if ZSA is a good platform to get stablecoins with privacy features. We definitely think it’s a core use-case!

We also had informal talks with the community at Zcon4 that showed excitement over the possibility of stablecoins on the Zcash ecosystem. Supporting stablecoins over ZSAs would clearly be a huge opportunity for Zcash, and we believe it will reinforce the underlying ZEC.

Stablecoin Issuers are Centralized

Stablecoins are inherently centralized assets. This is because they must be issued against collateral, which would be held by the issuer. The issuer is thus a point of failure, and needs to comply with authorities. This cannot be done when the Assets are completely untraceable.

The next-best approach is to maintain the privacy over the network via the existing ZKP approach of Zcash, while also giving the issuer the ability to view transactions over their issued Assets — thereby allowing them to answer regulatory questions about their stablecoins.

We have to account for regulatory pressure

The largest stablecoins are backed with USD or EUR etc, which are kept in regulated financial institutions. To successfully launch stablecoins over ZSAs, issuers require tools to comply with anti-money-laundering (AML) and other regulations.

ZSAs could offer a pragmatic approach using verifiable encryption

Verifiable encryption allows one to prove some property of the plaintext that has been encrypted. This can be used to encrypt transaction details that only the issuer can decrypt. At the same time, the consensus will be able to verify that the appropriate metadata was properly encrypted.

Additional User Control

In certain use-cases, users may wish to refuse a payment arriving to them. We expect that as stablecoins emerge on ZSA, there will be more demand for such control. We suggest to provide control to users regarding which incoming transactions they accept. This feature might facilitate the onboarding of ZSA in exchanges, allowing to accept only certain assets.

Exchange Compatibility

It will be important to develop means to include meta-data information along with transactions. Being able to prove properties about this metadata will allow for more fine-grained disclosure by users. This also aligns with ECCs vision of providing tooling to allow for optional compliance.

Our 2024 Roadmap

Given this motivation and background, we now delve a bit deeper into our proposed roadmap for the year. We note that these features will be optional, and need to be enabled before use.

1. Stablecoin Compatibility

We propose enhanced viewing keys for the issuer of an Asset, using verifiable encryption. This allows stablecoin issuers to privately view transactions involving their Asset (aka the stablecoin). This gives them the ability to prove to authorities they aren’t enabling illegal activities, while maintaining privacy for other users.

We have already begun the groundwork of implementing a proof-of-concept for verifiable encryption on Halo2. Since Halo2 is the proof system currently in use on Zcash, this will allow us to reuse existing schemes. We also have a technical document describing our initial efforts in this regard.

2. User Control

We’d also like to add support for recipients to approve transactions before accepting funds. Exchanges could use this to satisfy themselves about the source of funds before they accept them into their accounts. This design builds on top of our work designing Asset Swaps [2].

3. Exchange Compatibility

Exchanges would prefer to have means of knowing that the parties they provide services to do not fall afoul of AML or other regulations. At the same time, there is a need to allow for user privacy to be preserved without revealing unnecessary information. Therefore, simultaneously to the above, we will create a technical report analyzing identity on blockchains. Our goal is to look at the existing techniques used, to come up with ways to disclose just the information required while preserving privacy.

Risks and Mitigation

• We have taken all possible precautions to ensure that the complete protocols are tangible (e.g. the proof-of-concept for verifiable encryption described above), but there is a small risk that we come to the conclusion that the complete protocol is not efficient enough. This risk will be mitigated early in the protocol design stages.
• The presence of the enhanced issuer viewing key creates a point of failure for transaction privacy at the issuer. If the issuers viewing key is compromised, then the attacker can view the entire transaction graph of that Asset. It is important to note that the compromise is limited to the individual Asset, and does not provide spend or issue capabilities to the attacker. The rest of the pool continues to enjoy privacy as normal. Users can choose not to transact with Assets they do not trust to meet their privacy standards.
• The implementation of these additional features may increase the complexity of the protocol and impact performance. We will mitigate this by optimizing our implementations and providing clear documentation of our work.

Milestones

Milestone	Title	Work Type
1	Enhanced Issuer Viewing Keys for Stablecoin Compatibility
1.1	Enhanced Keys Research	Research
1.2	ZIP	Design
1.3	Implementation - Encryption + ZKP	Dev
1.4	Implementation - Protocol	Dev
1.5	Implementation - Zebra	Dev
1.6	Integration & Deployment	Dev + Coordination
2	Transaction Acceptance for Improved User Control
2.1	Design + ZIP	Design
2.2	Implementation - Cryptography	Dev
2.3	Implementation - Protocol	Dev
2.4	Implementation - Zebra	Dev
2.5	Integration & Deployment	Dev + Coordination
3	Identity Schemes for fine-grained disclosure
3.1	Report	Research

The expected budget is roughly $215k per month of work, covering a team of about 8-9 engineers and contributors.

We welcome any feedback from the community. Please let us know your thoughts on these capabilities!

Acknowledgements

The QEDIT team involved in writing this proposal includes Pablo Kogan, Antoine Rondelet, Alexey Koren, Constance Beguier, Yao Galteland, Jonathan Rouach, and Vivek Arte (myself).

We would like to thank the following individuals and teams for their help in discussing these ideas, their impact and their possible implementation: Jack Gavigan, Josh Swihart, the ECC core development team and the ZF development team.

---

[1]: The QEDIT team had proposed and implemented Zcash Shielded Assets (ZSAs) on Zcash. We’re currently in the midst of enabling ZSAs on the Zcash mainnet in time for the next network upgrade. The ZSA proposal is here. See ZIP 226 and ZIP 227, and a demo of the ZSA functionality, for more details.

[2]: We proposed last year to develop the Asset Swap functionality. We have presented a design in ZIP 228, which is under review.

[Jgx7]

Yes. This would move us forward in the very good direction. Ideally, Zcash would control the float to earn the yield on RWA which helps to subsidize the transaction costs and can be used to also pay yield for staking. I also believe this is a critical path to getting rid of inflationary funding while also keeping transaction costs low. Next, If we could use ZSAs to also let private enterprises tokenize their privately owned shares, that could be a massive opportunity as well.

[joshs]

Thanks, @vivek and team. I’m cautiously optimistic about this possibility, though I’ve yet to read the underlying materials.

Why caution?

I’m not here to build tools that have the potential for abuse by overzealous regulatory regimes, and I believe we need a Zcash stack that operates with complete independence - a new system outside the old system. I’m also concerned about sliding into a trap of expectations over time. We must not build anything like identity or censorship tooling into the protocol. It would be the death of this project. Zcash must remain privacy-protecting and permissionless.

That said, I believe in self-sovereignty and giving people a choice. If separate KYC-enforcing pools and supporting software are created on top of the protocol that people can choose whether or not to interact with, I’m all for it. After all, the protocol itself is permissionless and it’s up to each person to make that choice.

Stables for payments are an important innovation, and making it easy to opt into using them while ring-fencing Zcash itself could drive a ton of utility and adoption. I am glad that Qedit is proposing novel and useful options. Ultimately, I’d like to create a world where shielded stables without KYC requirements.

[hanh]

Thanks for the proposal, it is quite exciting to see a path toward stablecoins!
Are you concerned that the authorities would coerce stable coins issuers to hand over a copy of their viewing key or should the users expect it? In that case, the privacy would apply to the regular users but not the authorities. Is that right?
Also, there is a second critical requirement for stablecoins: Being able to lock a given address and deny any transfer from it. Would it be covered?
Finally, from a purely practical point of view, it seems that basic ZSAs aren’t available yet. Considering the substantial funding that went into ZSAs (basic + swap), wouldn’t it be reasonable to get the first version to market before signing up for more work? It is building up to be quite the pipeline.
Again, great work. I am looking forward to trying out ZSA in production!

[kworks]

Thanks @hanh, you have highlighted a very important issue.

Finally, from a purely practical point of view, it seems that basic ZSAs aren’t available yet. Considering the substantial funding that went into ZSAs (basic + swap), wouldn’t it be reasonable to get the first version to market before signing up for more work? It is building up to be quite the pipeline.

Let’s see ZSA live in NU6 first before more multi-million usd commitments are invested!

[_jon]

Thanks Josh, caution is def needed!

Agreed, the core operation of Zcash should be permissionless, fully private, with no outside dependencies.

This proposal allows an opt-in decision for users : if you choose to interact with large regulated stablecoins, this introduces a dependency on the issuer and their requirements, because they hold the underlying assets.

I’m sure we’ll have lots more to discuss with the ECC, ZF teams on how to ring-fence these more regulated coins, and the proposed mechanism of verifiable encryption.

[nextiscrypto]

Absolutely agree with hanh here, lets take things one step a time

[_jon]

Yes, privacy only from other users, for those who choose to use the stablecoin.

For locking addresses, since ZSAs are utxo, that’s a finer granularity, but even then we’d need to be really sure this is needed. In USDC, For example, those are quite rare events, it happened altogether about 200 times. So the issuers might have alternative ways to comply, without needing protocol changes.

Regarding ZSAs in prod: we’re happy that all the ZIPs were accepted, and we were able to deliver core-ZSA successfully.

Now swaps + integration work is underway, which is a coordination between all Zcash devs, especially with Zebra.

We’re proposing this roadmap now both because we cleared ZSA-core, and because building these systems takes quite some effort.

I’d be really happy to start actual UX trials of ZSA in YWallet, btw! It would make our deliverables much more visible to the wider dev community. Maybe we can leverage the working demo for Zcashd?

[Jgx7]

@kworks

Finally, from a purely practical point of view, it seems that basic ZSAs aren’t available yet. Considering the substantial funding that went into ZSAs (basic + swap), wouldn’t it be reasonable to get the first version to market before signing up for more work? It is building up to be quite the pipeline.

Cant we say the same thing about ECC, Foundation and ZCG with regard to getting block reward funding (especially ZCG who has so many unfinished projects)? It’s important that we continue to fund critical development such as ZSAs and Stablecoins and stop funding for non critical. I’d much rather see you try to block non critical non development funding.

So, making sure stablecoins are fully funded is important. We should really think about a direct allocation of block rewards to Qedit.

This type of planning and visibility is what we need as opposed to undefined blank check funding.

[hanh]

@_jon

For locking addresses, since ZSAs are utxo, that’s a finer granularity, but even then we’d need to be really sure this is needed. In USDC, For example, those are quite rare events, it happened altogether about 200 times. So the issuers might have alternative ways to comply, without needing protocol changes.

I suppose “rare” is subjective. USDT has nearly 1 billion dollars locked. https://dune.com/phabc/usdt---banned-addresses. Besides, I think for the regulators, it is a matter of having the power to block, not so much about how many times it was used.
Could you clarify how the issuers would find ways to comply?

@_jon

Regarding ZSAs in prod: we’re happy that all the ZIPs were accepted, and we were able to deliver core-ZSA successfully.

This may be my ignorance. I was under the impression that the grant was more than writing ZIPs. Isn’t Core ZSA finished when it is activated in a network upgrade? It is going to be in NU6, right?
Besides, my point was about seeing the impact of ZSA on the ecosystem and how well received/used they are. To which, I’d be happy to help integrate into Ywallet once it is activated.

[_jon]

QEDIT delivered the implementation, now ECC+ZF are merging it and preparing for NU6. We’re putting efforts to support nu6, it’s one of our current milestones.

Regarding blocked addresses, you’re right, for USDT it’s 1% of funds, so maybe not that “rare”. USDT has 5x more market share, so that’s inline with 6x more bans than USDC.

However there’s an argument that ZSA stablecoins would behave in a similar way to BTC, from the issuer perspective, since we’d provide utxo-level visibility to issuers. BTC has had established law-enforcement practices for a while, and if you combine the fact that issuers have the power to refuse to redeem, as well as our proposed “transaction acceptance” mechanisms, the effects might be sufficiently close to blacklisting. For the regulators, these features are such a big departure from how they perceive privacy coins today, with such a strong compliance upgrade, that I think we can start here.

If you have reasons to believe otherwise, happy to chat and we will advise here. [Same goes to any stablecoin compliance people reading this, btw! ]

[joshs]

@_jon

now ECC+ZF are merging it and preparing for NU6

We at EC have not assumed this will be ready for NU6. We assume that it is a target for NU7 in early 2025 to account for audits, testing, etc. @_jon, let’s discuss this on our call this week.

[pkr]

Seems like a major miss then. Why did @_jon think that was ever the case?

[_jon]

We’re currently working on version 6 transactions that are compatible with Orchard and ZSA, in prep for nu6. Some of this work will help test nu6 transactions regardless of ZSA (the Zebra test framework), so we’re coordinating on this with ECC+EF teams. If we hand it over in time for nu6 but then it goes in at nu7 because there’s a consensus that more testing should be done, that’s a choice for quality, we’d support that.

[joshs]

The other factor, that I forgot to mention, is that zcashd depreciation needs to be done as well. I suspect that most of that work will be ecosystem related. We’ve all got a lot of coordination to shore up.

[hanh]

@_jon

QEDIT delivered the implementation, now ECC+ZF are merging it and preparing for NU6. We’re putting efforts to support nu6, it’s one of our current milestones.

Let me use an analogy here. You guys are the actors and directors of the ZSA movie. Script and principal photography are finished. It’s a wrap. You want to move to the sequel.
For me (as an investor) who has only seen the trailer, I would like to get post-production, marketing, and release. More importantly, I would like to get the box office numbers before I greenlight the sequel.
As a developer, I understand you want to continue working.

@_jon

However there’s an argument that ZSA stablecoins would behave in a similar way to BTC, from the issuer perspective, since we’d provide utxo-level visibility to issuers. BTC has had established law-enforcement practices for a while, and if you combine the fact that issuers have the power to refuse to redeem, as well as our proposed “transaction acceptance” mechanisms, the effects might be sufficiently close to blacklisting. For the regulators, these features are such a big departure from how they perceive privacy coins today, with such a strong compliance upgrade, that I think we can start here.

Does it mean that the issuers would recognise the UTXOs that are to be blocked and refuse to redeem for FIAT? But would it be possible for them to block the usage of these UTXOs to swap with other ZSA (and then lose track)?

[joshs]

Hi everyone.

@_jon and I spoke this morning about the current state, timelines, and this proposal. Our goal was to clarify misunderstandings about the current delivery and estimated timeline.

On ZSAs

If you are not aware, Qedit built the cryptography and code for zcashd initially, but had to shift to zebrad, effectively doing two software projects. This was due to the decision to deprecate zcashd.

The NU6 timeline mentioned is related to the completion of their work. The code will be ready. It’s up to the ZF to merge the code, and auditing and testing can begin.

This doesn’t mean it will be activated on mainnet by then. We have to account for various moving pieces including the time to merge, audit, test and remediate safely. Additionally, we can not activate ZSAs on mainnet until zcashd is deprecated.

Net: Qedit is hitting its milestones despite the increased workload, but the likely target for activation on mainnet is Q1 2025 with NU7.

On Stables

Jon and I have committed to continued dialogue on the design and tradeoffs, and to share thoughts here. At a minimum, he and I have scheduled biweekly meetings to check in and the teams will continue to engage as well.

In the design, we agree that the goal is for Zcash to remain pristine but also to support people who want to opt-in to shielded stables with full knowledge of what information is being shared with the issuer. We also agree that this could be a game-changer, bringing a lot of people into Zcash because they want the privacy of a shielded stable with the reputation of Zcash.

But that’s just us and we need the community to collectively dig in and interrogate the design and ask hard questions. There are interesting and novel concepts. There is no need to wait to get that part of this started. The funding conversation can happen subsequently.

[GGuy]

Zcash Community! We have a big decision to make. This proposal, if funded by ZCG, would use up all (and more) of our available ZEC. We need your feedback! What should we do?

[Jgx7]

Fund it; ZSAs/Stablecoins are a critical development project that will help Zcash to become a blockchain of money.

As it relates to ZCG, I would cut all non critical a) non development expenses b) third party wallets, and c) Media expenses and focus on core engineering and blockchain development grants only for the next few years. Yes its a hard thing to do; but necessary. Its only by making the Zcash blockchain have more utility that its price will rise and maybe provide more resources again in the future. We need 1 very good wallet only–Zashi. ZEC is for holding (like BTC). As M. Saylor so eloquently stated recently, “I dont see people who own buildings selling off a fractional interest to buy coffee” Very funny and very true…ZEC is digital gold like BTC. Once this is understood, it helps to change what gets funded. Sure a person can carve off a piece if they need to. But its not designed for short term day to day transactions, its designed to retain purchasing power over long periods…So, we really dont need any third party wallets once Zashi is released, we do need to be integrated into existing wallets like Metamask, Brave, and Ledger etc, and a DEX (Maya) and ideally we could integrate their assets into Zashi much like the way Metamask works.

As you can see below (very rough calcs), a lot of money has been spent on third party wallets. We can and should cut future funding as fast as possible, as well as other future funding for non critical spending (such as the incomplete videos).

Approved	$12,582,548.18
		%	Type	Status
Nighhawk	$1,142,986.00	9.08%	wallet	Non Critical
ZEC/Zingo	$982,174.00	7.81%	wallet	Non Critical
Hahn	$1,015,168.00	8.07%	wallet	Mostly non critical
Media	$1,361,470.00	10.82%	mostly videos	Non Critical
Free2Z	$468,037.00	3.72%	?	Non Critical
ZGO	$255,100.00	2.03%	payments	Non Critical
Qedit	$2,949,863.00	23.44%		Critical
Equilibrium	$1,064,200.00	8.46%		Critical
Maya	$45,200.00	0.36%		Critical
Tor	$1,339,856.00	10.65%		Completed
Other	$1,496,261.18	11.89%		Mostly done
ZECHub	$128,750.18	1.02%		Critical
Avalanche	$210,433.00	1.67%		Critical
Zondax	$101,800.00	0.81%	wallet	Critical
Nym	$150,000.00	1.19%		Non Critical
	$12,582,548.18	100.00%

It’s not even a question that Qedit gets funded is it?

ECC/Qedit both think opt-in to shielded stables would be a game changer. I happen to agree with them 100%. Stablecoins are very low risk assets that will continue to dominate day to day spending for the rest of our lives. They are also what will give the Zcash blockchain the quality assets needed to scale. Stablecoins (and some forms ZSA) are the future of day to day transactions for as far as a person can see.

@joshs

We also agree that this could be a game-changer, bringing a lot of people into Zcash because they want the privacy of a shielded stable with the reputation of Zcash.

If after cutting all non critical spending, put together a plan as to why ECC (with its very solid reserves thanks to Stark and BLD) or the Foundation (with its BTC or Eth) should finance a portion of ZCG funding shortfall. But ECC/Foundation should only be assisting for short term and for critical development.

Once ZcashD has been deprecated, we have privacy by default, moved to POS, have ZSAs/stablecoins, Zashi is fully functional with integrated DEX and all, and it all works ultrafast and is bullet proof, then we would have something people can trust and start allocating more money to in the future.

[Shawn]

@GGuy

We need your feedback! What should we do?

Let’s see ZSAs running on mainnet first, then worry about what assets to make as ZSAs. We are not even scheduled to see the baby steps (bugs/problems, uptake rate) of ZSAs before Q1 next year so spending a massive amount of the ZCGs funding so far in advance seems very premature.

Personally I would rather see zBTC, zETH or zNFTs integrated before stablecoins because there’s less risk of running into the regulatory problems described above and think they would attract more everyday crypto users.