Zcash Shielded Asset Swaps and Transaction Acceptance

Community Grants Applications
1

Dear Zcash community,

As most of you would be aware, based on conversations with ECC, ZF and the community, Zcash Shielded Assets (ZSAs) are on track for deployment in NU7! You can keep track of our updates on this thread, and in the 1500 UTC Arborist calls.

In parallel to the work of getting Zebra ready for ZSA and launch of a testnet, we have proposed a new grant to implement core ZSA features. Based on community feedback, we will be focusing on two main goals — the implementation of our ZSA Swaps ZIP that we submitted earlier in this year, and the research and design for a feature allowing users to accept / reject incoming transactions of ZSAs.

Asset Swaps Implementation

We worked on our design for Asset Swaps in ZIP 228, and would love to hear any comments on the ZIP. Please also check out our ZconV talk and slides for a high level overview of the design.

zip-0228-swap-bundle
zip-0228-swap-bundle1346×1600 304 KB

Since there is a strong community demand for Asset Swaps being added to the ZSA capabilities, we will be working on the implementation of the protocol as described in the ZIP as a part of this grant. We will also work on tooling so that it is possible to interact with and test the protocol.

Transaction Acceptance

The aim of this work is to provide recipients with the ability to only receive transactions that they approve of. An example is a scenario where a user does not want their wallet to be flooded with “spam” ZSAs, or only wants to receive specific ZSAs. Another example use case is that of exchanges receiving funds from users for conversion. The exchange might want to verify that the sender of the funds meets the necessary requirements before proceeding with the transaction.

We offer a method for recipients to approve transactions by providing an approval signature for the funds they wish to accept. This idea builds on top of the Asset Swaps design we have in ZIP 228, and would likely work on a per-transaction basis. This should allow wallets to make use of the functionality to provide different sorts of features to end-users, such as automatic approval for a specific asset. Thus, users can choose their level of granularity — discerning users might want to decide their acceptance for each transaction, others might be comfortable with a more general “accept any transaction of these tokens but only these tokens” approach.

Unlinkability is another important consideration here. Our design ensures that the recipient’s “acceptance” of an incoming transaction does not reveal any information about them.

This is an initial draft design, and we look forward to discussing the details with the engineers and the community as we coalesce into a ZIP for this feature, which is the deliverable of the proposal.

We had an initial discussion about this during the Arborist Call held on 25 July 2024 in the 1500 UTC timeslot. We’re interested to hear views from the broader community as well, so please let us know what you think!

Best,

The QEDIT Team.

17 Likes
2

Onward and Upward ZSA :rocket:

1 Like
3

I am grateful for the QEDIT team’s contributions to Zcash.

When they first submitted and got approval for the ZSA proposal, I was excited and had high expectations. I thought ZSA would be implemented quickly. After the grant period ended, I expected to see Zcash-based tokens like zUSD and zBTC being launched and the Zcash ecosystem becoming active, but nothing has changed so far. As I am not a developer, I might not fully understand the situation, but as a Zcash holder, I feel disappointed.

This new proposal requests $650,000. The total number of team members is four, and the estimated completion date for the milestones listed in the proposal is December 1, 2024. I hope the ZCG committee carefully considers whether it is appropriate to spend $650,000 over four months for a team of four members.

image
image1831×774 177 KB

I do not believe that the amount they have been paid so far is insignificant. As development costs decrease, please confirm whether additional funding will be required for ZSA next year after the proposal is approved and implemented.

2 Likes
4

It seems from last week’s thread on stablecoins I extracted information that Qedit needs constant Zcash funding.

1 Like
5

imo, this isn’t useful at this time. Without zsa, there aren’t zsa swap. Without programmability on chain, there are no automatic market maker.

3 Likes
6

Hello QEDIT team. I’ll try to provide my feedback in a honest and respectful way. The impression I have is that your team is always delivering* just enough, leaving a “cliff hanger”, in order to start a new proposal application.
* Maybe not even delivering, but implementing, since I believe ZSAs aren’t deployed yet.

Let explain what I mean:
Since I first learned about Zcash few years ago, I’m hearing about ZSAs. One use case people mentioned was stablecoins, so I thought stablecoins was going to be a feature from the get go. Later you guys came with a new proposal saying “You know, ZSAs are cool, but they’re kinda useless, if you want something useful, let’s bring stablecoins to it”. To be fair, I understand bringing stablecoins is more complex than just the technical aspect, there is legal aspects also.
But now, I’m starting to believe even the vanilla ZSAs are suffering the same, it sounds like “ZSAs are cool, but if you want it to be useful we need to implement asset swaps”. Isn’t swapability suposed to be a integral part of an asset?
Let me make an analogy and try to express my criticism more clearly…
Imagine I get funded to design and build a car.
So I deliver this beatiful car with a powerful V8 engine.
But then I come back and say "You know, this car is very powerful, but it doesn’t have a transmission, if you want a way to transfer all the power from it’s engine to it’s wheels, I’ll need more funding to add a transmission.
Then I get a new stream of funding …
And then I come back and say “Well, the car is very fast. But it’s dangerous to drive it, since it has no breaks! I’ll need more funding to add breaks to it.”
And so on …
Bottom line is, all these “extra features” shouldn’t be extras at all. Every one of these features should be expected, since they are what makes a car to be a car.
That’s my criticism, I believe asset swaps and whatnots should already be implemented since the begining, since all these features is what makes an asset to be considered an asset …

I’m a fan of QEDIT, but sometimes I fell your proposals are an excuse for the next proposal.

Sorry if I was harsh, since english is not my first language, it might sounded rude, it wasn’t my intention.
Good luck with your application!

4 Likes
7

i have had similar impression for most time that the ZSAs would be a whole working system. until recently i understood its not quite and its built in parts in a way. :man_shrugging:

8

I have reviewed the grant proposal User-Control for ZSAs. To clarify, given the name of this thread, this proposal is just for the user transaction acceptance feature. It does not include the asset swap work which is covered by an existing approved USD 1.8m grant.

I have no objection to this feature on privacy or other technical grounds. There is only one line in the grant application about the proposed technical approach (requiring a receiving party to provide a signature in order to accept each payment), but that’s certainly feasible and can be done in a privacy and consent-respecting way, which would need to be opt-in (presumably per spend authority or address).

From a forward-looking cryptographic design perspective I believe we need to upgrade to post-quantum authentication in the medium term, but it’s fine to use DL-based signatures while the rest of the protocol uses them, and this feature needn’t be an obstacle to a post-quantum upgrade.

On the issue of value-for-money, the grant proposal is for USD 650,000, explained as follows:

The expected budget is roughly $85k per month of work, covering a team of about 4 full-time ZKP and protocol engineers.

That works out to 7.65 months’ work for 4 full-time engineers. My main negative comment is that I do not see that amount of work in this feature (even if “full-time” is interpreted to mean they are working full-time on this feature and asset swaps). It has been suggested informally that this feature might reuse some of the preliminary design work done in the context of the cancelled compliance grant, but even assuming ZCG considers it appropriate to retrospectively pay Qedit for any parts of that work that are reusable in this context and privacy/consent-respecting, I don’t see 7.65 months’ work for 4 full-time engineers here. I would recommend that the ZCG committee negotiate down the price.

7 Likes
9

On a procedural / governance point for ZCG, not related to this proposal specifically, it seems that all Rejected, Withdrawn, and Cancelled grant proposals are removed from the http://zcashgrants.org website. For example, the cancelled compliance grant was at https://zcashgrants.org/gallery/25215916-53ea-4041-a3b2-6d00c487917d/46497294/ which is now a 404. For transparency, I think that Rejected, Withdrawn, and Cancelled proposals should be retained indefinitely, with a header showing their status.

4 Likes
10

Thanks for taking the time to look at our proposal!

We do include Asset Swaps work. Please refer to the proposal you’ve linked, this proposal is for the following deliverables:
1.1 Asset Swaps Protocol Implementation
2.1 Asset Swaps Implementation: Zebra and Testing Tools
3.1 Transaction Acceptance Research and Design
4.1 ZIP for Transaction Acceptance

It’s possible that you missed the conversation about QEDIT helping the Zebra effort.
We didn’t allocate a new grant for this effort, because the price of ZEC was so low, and ZCG wanted us to prioritize Zcashd deprecation over new features.

So for Asset Swaps we managed to provide deliverable 6.1 Asset Swap ZIP, and now we’re proposing to build the implementation.

Maybe you got confused because our current proposal is actually under-representing the amount of work and engineering required, for both the new user-control feature and for the implementation of Asset Swaps. We decided to propose this grant within the amounts granted in the (now cancelled) compliance research grant. We also expect more engineering joining this effort once they clear more Zebra work.

I hope this helps.

11

Here are all the mentions of asset swaps in the new proposal:

This is a proposal to introduce a mechanism to allow parties to confirm and reject incoming transactions. Simultaneously, we also propose to work on the implementation of Asset Swaps.
[…]
This design builds on top of our work designing Asset Swaps.

I don’t see anything concrete about additional asset swap functionality beyond the existing Zcash Shielded Assets - Asset Swaps and Beyond proposal approved in May 2023. That proposal includes implementing asset swaps, supporting their integration in Zebra, deploying them to a testnet that Qedit maintains for 12 months, facilitating a security audit, and wallet adaptation.

According to its status page, milestones 1, 6, 7, and 10 are complete, for which the deliverables are:

  • Testnet infra and manifest setup
  • Asset Swaps ZIP
  • Development in Support of Zebra (1 of 2)
  • ZSA compatibility with Orchard

The overall cost was USD 1.8m with USD 900k paid up-front, a total of USD 343k for those four milestones, and USD 557k for the remaining deliverables.

Obviously, asset swaps depend on ZSAs and so could not be deployed with NU6 as originally anticipated in that grant proposal, and that was beyond Qedit’s control. But there were no external factors blocking their deployment to a testnet, and clearly deploying them to a testnet requires having implemented them.

So for Asset Swaps we managed to provide deliverable 6.1 Asset Swap ZIP, and now we’re proposing to build the implementation.

Yes, which is included in the remaining USD 557k for the existing grant. As I read that grant,

Asset Swaps Protocol Implementation
Asset Swaps Implementation: Zebra and Testing Tools

are already included in its scope of work. Specifically, “ZSA Transaction Testing for Zebra Implementation PR” is milestone 2 and “Asset Swaps Protocol Implementation” would have been necessary for milestones 4 and 5.

It’s possible that you missed the conversation about QEDIT helping the Zebra effort.
We didn’t allocate a new grant for this effort, because the price of ZEC was so low, and ZCG wanted us to prioritize Zcashd deprecation over new features.

I didn’t miss it. Note that the above asset swaps grant includes “Development in Support of Zebra” as milestones 8 and 11. It’s unclear whether that was specific to asset swaps or not. I appreciate that it has been helpful for Qedit to adapt to the work that is actually needed.

In any case, Qedit is free to formally include additional development in support of Zebra in this or a new grant proposal, but the current proposal does not include it, and the current proposal is what I reviewed.

Maybe you got confused because our current proposal is actually under-representing the amount of work and engineering required, for both the new user-control feature and for the implementation of Asset Swaps.

I don’t think I am confused about estimation of engineering effort required for Zcash protocol features, which is part of my job as ECC’s R&D engineering manager. (Admittedly I have occasionally underestimated that in the past, but mainly due to underestimation of unanticipated competing engineering demands, rather than the effort needed for any specific feature.)

If I’ve misunderstood and part of the amount allocated to the new grant replaces some of the milestones in the existing grant, then that’s different. But there’s nothing in the proposal or elsewhere on the zcashgrants.org site that suggests that would be the case. (And if so, the new grant proposal should explicitly include those milestones.)

1 Like
12

This is correct. Given our limited budget and the urgency of depreciating zcashd, ZCG encouraged QEDIT to amend the Asset Swap grant to replace some of the project milestones with deliverables focused on zcashd depreciation. In light of the stablecoin grant cancellation, it makes sense to include the milestones removed from the Asset Swap grant in this new grant proposal.

13

I strongly suggest that if grants are amended, that needs to be reflected on the zcashgrants.org site. Otherwise it is literally impossible to review new grants to check for duplication (paying for the same or substantially overlapping work several times), among other issues. This information should not only be informally tracked by ZCG committee members and grant recipients, it has to be transparently communicated.

Note that it’s completely infeasible for someone reviewing a grant to comb through minutes of previous ZCG meetings. It wouldn’t be a good use of our time.

2 Likes
14

I agree with you. I’ll reach out to ZF to check if Submittable has any audit trail features. They might be able to generate something on the backend. We’ll follow up with you on Monday.

3 Likes
15

Thanks. I’ll re-review the proposal once it has been clarified what it does and doesn’t include, and what has been removed or changed in the existing overlapping grant(s).

2 Likes
16

Do you have these charts in ZEC? ZCG does not grant USD.

17

wait. we should start publishing grants just on github imo. :thinking:

all history and edits would be public and easily implementable into some front-end.

3 Likes
18

Coincidentally, @GGuy has already pitched this and demoed it for us yesterday. We’re planning to discuss it with FPF and may transition to it in the next couple of months.

5 Likes
19

I agree, and that would help in future. Note that:

  • It doesn’t necessarily address historical issues, including this grant, unless someone does the (considerable) additional work of putting those in GitHub.
  • The issue with the asset swaps grant was, if I understand correctly, that it had been effectively changed but the document not updated at all. Having it on GitHub wouldn’t have caused the necessary work of updating it to be done.
  • git history is incredibly useful once you know there is an issue. It would be somewhat cumbersome and work-intensive to delve into the history as a normal part of review. So it’s also important for the page that you’re immediately presented with when doing a grant review to call out any substantive changes (and not call out purely editorial changes; that would just be noise).
2 Likes
20

:point_up_2: :+1:

1 Like