The short answer is that although there is an audit trail on the backend it wouldn’t help at all with the type of review being discussed. While Submittable has met many of our needs over the past years it’s far from perfect, especially when it comes to this type of grant comparison. I wish I could provide a more helpful response!
We timed the Submittable contract renewal so that ZCG could decide what direction to take in November. FWIW, I personally 100% support a move to GitHub (or another solution if one is found). It’s time to try something new and the timing is perfect with the upcoming ZCG move to FPF.
For completeness, here’s the Asset Swap milestones from the original proposal:
From this original grant, we’ve done part 1 (ZIPs), we’re now proposing part 2 (implementation)
As noted above, part 2 was replaced with Development in Support of Zebra, specifically Deliverables 7.1, 8.1, 11.1. You can see the replaced milestones here.
We will apply for a separate grant for part 3 when it’s ready. Part 3 depends on progress from ECC/ZF (integration of asset swap), it’s not included in this new grant, because it’s in the future and requires more effort and funding than what ZCG wished to allocate for the current grant, already including the Transaction Acceptance work.
Hope that clarifies the grant, thanks for helping us put this on the record.
Btw a move to Github would make our lives easier, Submittable is cool but we do prefer our local editors and history + state management for exactly the current usage.
@vivek at the most recent meeting, the @ZcashGrants Committee voted to approve this proposal and has requested that you provide monthly updates via the forum in this thread.
We have begun updating the orchard crate to add support for Action Groups as proposed in ZIP 228.
We are currently working through what changes to the OrchardZSA circuit (if any) would be required in order to securely allow for Swaps.
We are also in the midst of creating new data structures / updating existing ones for the Orchard Bundle, the Orchard Action, and the Orchard Action Group.
While the protocol itself will require development and tests in the repositories listed in the previous section, actual use by the community would require the ability to create Swap Orders, and also to match these Swap Orders, create a Swap Bundle, and submit that on chain.
The Matcher is designed to collect Swap Orders, match them efficiently, combine them, and submit the complete Swap Bundles to the blockchain.
The architectural design for the Matcher is currently underway.
We will also be updating our zcash_tx_tool, which we have been using to generate transactions for Zebra nodes, to also be able to generate Swap Orders on the client side.
Transaction Acceptance (User Control) Design
We have begun research into possible designs to add the proposed ability to accept / reject incoming transactions.
Here’s a list of some of the questions we are thinking about in this regard. Please feel free to raise more!
One core design consideration is regarding the default behavior: i.e. requiring explicit approval vs explicit rejection from the recipient. The use-cases are one way of assessing this.
What is the threat model? We have to consider in the threat model both malicious senders (who want to expose other users to Assets they do not consent to, for example), and malicious recipients (who could try to hold up funds by not providing explicit approval, or fall back on deniability if they didn’t provide explicit rejection).
Should the approval/rejection of a transaction be stored on chain, or can it just happen off-chain between the sender and receiver?
Who should pay the fees, and should there be extra fees for acceptance/rejection? This is more relevant if an on-chain record is to be maintained. But the responsibility of submitting to the chain moves from the sender to the recipient (post-approval), which needs to be considered as well.
Extent: Should this user control extend to every transaction, or only transactions of larger than a certain threshold, or only ZSAs, and so on? While answering this question we have to be mindful about indistinguishability. If we allow the choice per transaction, the choice should be the recipient’s.
Is asset swap actually desirable when Zcash block time is 75 seconds? With no fast finality, the opportunity cost for traders could be too expensive. I would prefer external DEX integration for ZSAs instead.
I feel strongly about the topic because I think because often a “product” view has gone missing in Zcash.
The ability to swap, trustless, between two assets has been the biggest use-case of Crypto so far (Maybe Polymarket is going to be bigger). Thinking that “for Zcash is different” is a bit naive I think. Also:
there are people buying Bitcoin Runes with the Bitcoin block time,
and Zcash block time is not there forever, and likely revisited with a PoS implementation
One thing for me that is not yet clear, is how we pretend to launch DEX’s without this “swap functionality”. I’m probably missing something.
But imagine how sad would it be if we got ZSA’s but had to trade them in a centralized exchange because we missed the deadline to include the swap functionality
Who is launching a dex? I might’ve missed it but I’ve never heard of a dex idea when ZSA was being proposed. ZSA was about the ability to transfer assets other than ZEC on the Zcash network.
Maya DEX will integrate Zcash, and I think they can also integrate ZSA in the future.
But anyway, to my point: how will Maya DEX be able to trade between ZSAs without having the proposed ZIP of “Swap”? That’s the part where I’m confused. @vivek@daira (sorry to tag you two, but maybe you can help?)
Also, I’m not against the swap feature for ZSA. Just that prioritizing it now is useless since ZSA is not even launched yet and ZSA swap development will take some time. So, why not prioritize ZSA launch, then get Zcash some fast finality before adding the swap feature?
We’re sharing here our progress in the last few weeks on the Asset Swaps implementation and transaction acceptance design.
Asset Swaps ZIPs
We have updated the formula for the Spend Authorization Signature so that it can be computed by the party preparing the Swap Order.
We have also prepared an update that would allow the Action Group changes to the transaction format to be included within the V6 transaction format. This would have the advantage of reducing the need for a second transaction format upgrade.
We have prepared a first draft of the changes to the orchard crate to add support for Action Groups and Swap Bundles as proposed in ZIP 228. You can check this out at PR#116.
We are currently exploring ways to handle the reference note required to generate an action group. This is to handle the situation where a user would like to receive assets that they have never owned before. Generating the output notes for the Swap Order in this case is not trivial and requires careful planning.
We have created various new data structures / updated existing ones for the Orchard Bundle, the Orchard Action, the Orchard Action Group and the Swap Bundle.
We will be updating our zcash_tx_tool, which we have been using to generate transactions for Zebra nodes, to also be able to generate Swap Orders on the client side.
Using this tool will provide the functionality to perform peer-to-peer Swaps for ZSAs
Transaction Acceptance (User Control) Design
We presented the transaction acceptance use cases at the ZSA bi-weekly meeting to the members of ECC and ZF.
We have been working on a document with designs for transaction acceptance while considering the questions raised in the previous updates.
We will be publishing the results to the Zcash forum (on this thread).
We completed the design of the reference note required to generate an action group in the situation where a user would like to receive assets that they have never owned before. We have made the implementation in the orchard crate.
We have also been implementing the changes to the librustzcash crate in order to support Asset Swaps as per the specification in ZIP 228. The draft version of this can be seen here.
We will also be updating our zcash_tx_tool, which we have been using to generate transactions for Zebra nodes, to also be able to generate Swap Orders on the client side.
Transaction Acceptance (User Control) Design
We shared a forum post with designs for transaction acceptance while considering the questions raised in the previous updates.
A preview of the rendered version of the ZIP is here.
Asset Swaps ZIPs
We have made various changes to the ZSA ZIPs to resolve issues. We are in the process of making these changes reflect correctly in the Asset Swaps ZIP design.
Could Zcash Foundation and Ethereum Foundation collab in providing liquidity with wrapped versions of each other tokens on the other blockchain to be traded through Maya?
Maybe…memecoins?
Ideally, our unicorn, would be a stable-coin issuer. @aquietinvestor any news…?
QEDIT talked to a team in Netherlands that wants to welcome ZSAs to their regulated exchange, with possible internal uses for a ZSA stablecoin changing hands as part of the exchange transactions.
When it gets more concrete we’ll be able to share more.
With Zcash itself, users took years to move from mainly transparent to mainly shielded, but the potential was very quickly recognized and it allowed safe iterations.
I think we should work hard to activate ZSA safely and early, and do the best job we can explaining why this is a game-changer for digital assets.
