Sapling withdraw-only discussion kickoff

General
1

We need to get all ZEC users quantum recoverable (QR). The community has already overwhelmingly voted YES to support this. The plan is at minimum that we must freeze all pre-quantum sound pools before cryptographically relevant quantum computers arrive.

Orchard is becoming quantum recoverable imminently. It’s a wallet-only upgrade. Users just need to update their wallet, and do a transaction. Then all their long term holdings are quantum recoverable, and they could safely walk away from computers for 10+ years.

So once QR is in wallets, the next step is getting all users off of non-quantum recoverable setups. Namely this means ensuring they move off of non-QR Orchard, Sprout and Sapling. After the next network upgrade (NU7) we will be able to publicly track the amount of wallet activity that is definitely quantum recoverable with Orchard. We can then assess if we need more drastic decisions to remove non-QR Orchard. (E.g. updating a circuit)

For Sprout, we have one of the longest forum discussions to date, and it’s expected to resolve with a token holder vote deciding the last date of the pool. (Choosing between remove support immediately, at an end-date one year out from the poll, or only as late as possible when we freeze all pre-quantum pools)

For Sapling, it’s time to start the discussion of what we do, to reach a decision. Sapling is not getting made QR. So we need to get the migration started. Sapling is currently 11.8% of shielded ZEC, and 18% of shielded activity, almost entirely from visible mining pool payouts. Since Jan 1 2024, the Sapling shielded ZEC has dropped from 1.1M ZEC to 600k ZEC as users migrate. The biggest lever to get folks off Sapling is imo to declare an end date by which Sapling becomes withdraw-only. The biggest known Sapling users are all the miners, and YWallet.

The miners are already beginning the transition to Orchard. Thanks to the legendary @zkclaudecoder , there is a pure rust, Zebrad-based mining pool live, with shielded in Orchard. It has been gathering hashpower, producing a few blocks on mainnet, and every single testnet block for months.

The Orchard pool is live in wallets, including Ywallet. So users should have ample time to fully move, without using the withdraw-only function. When withdraw only day occurs, they simply move into Orchard.

Its reasonable to begin communication for a sapling withdrawal-only process early, especially as we are going to be getting a fourth shielded pool (Tachyon) EOY. Hence kick starting a discussion here.

My suggestion is to remove Sapling deposits, and make it withdraw-only at a date 1 year out post decision. Where decision would come from the full token holder poll + committee polling on the topic, should they agree with the plan. (Likely then June 2027) Thoughts?

11 Likes
2

I’m wondering, are popular multi-crypto wallets that support Zcash - like Exodus, Cake, Atomic and Guarda - notified of drastic changes like these somehow? Most wallet conversations, considerations and checklists within the community seem to revolve around ZEC-only wallets, but the Zcash ecosystem is bigger than that. Let’s not forget the more casual users.

2 Likes
3

Here I’m trying to kick off the discussion! Everyone will get notified of this for thoughts especially once were later in the process and Token Holder Votes near starting for a decision. We will be reaching out to all the wallets to offer the vote to their users (and themselves opine). A token holder vote is absolutely a requirement for any change of this scale

5 Likes
4

I believe we need to get to a place where we can freeze old pools (as gently as possible) for the following two reasons:

  1. Non-Quantum
    This would allow us to shed a bunch of technical debt all at once. Therefore, we could have more engineering time allocated to new features and less risk of exploitation. Unfortunately, not everyone on the web is as honest as @scalar and @arielgabizon.

  2. Quantum
    Game theory suggests that it is sensible for an advanced threat actor to keep their possession of a cryptographically relevant quantum computer a secret for as long as possible. In practice, this means we cannot guarantee that we will see it coming. As the race to the finish line intensifies, we’ll see more and more speculation about whether an ancient Bitcoin address waking up is a genuine sign of a QC or just FUD. In contrast, if we have the problem fully solved by that time, we should continue to benefit from the ever-increasing quantum threat perception.

8 Likes
5

As far as I know, the main issue isn’t with user wallets designed specifically for Zcash – it’s not difficult to switch them to any mode via user interface. And many of them no longer support Sapling - Unstoppable, for example. Nor is it the wallets that support only transparent ZEC. The main users of the Sapling pool are some large custodians whose infrastructure is still based on this protocol.

2 Likes
6

Which custodians are using Sapling? We should bring them into this conversation.

3 Likes
7

I may be wrong, but it seems that Gemini uses Sapling addresses for deposits and withdrawals, even though they are part of the UA.

https://support.gemini.com/hc/en-us/articles/31670107364891-What-type-of-Zcash-deposit-address-does-Gemini-issue

1 Like
8

Starting the discussion now makes sense. From the operator side, Orchard-native payouts are already viable, the constraint is no longer transaction construction.

If Sapling goes withdraw-only, readiness criteria should be the trigger, not a date. Wallet support, coordination with exchanges, pools, custodians still touching Sapling, and public metrics showing Sapling balances and activity dropping.

The failure mode is not miners, they will move when the rail exists. It is passive users and long-tail wallet users getting stranded because the ecosystem assumes they are paying attention.

3 Likes
9

I have been pondering this proposal of yours and your earlier proposal about the long-term security budget (both of which I support). Both proposals address existential issues inherited from Bitcoin. I was wondering if we should make use of the remaining ZEC in the deprecated pools to fund long-term security while honoring the 21 million supply cap.

3 Likes
10

Readiness criteria over calendar dates makes sense. If exchanges still have users on Sapling when the switch hits, those users eat the pain. Migration tooling and exchange adoption should gate the timeline.

The quantum recovery case adds urgency. Worth doing soon, with clear checkpoints.

2 Likes
11

I’m not too sure which readiness criteria makes sense to codify, beyond usage of best-judgement.

Making a policy that “We will not make Sapling withdraw-only until Coinbase does {anything}”, … sounds pretty off for a decentralized project.

Orchard wallet support is high! Zodl, Ywallet, and Cake all use it. Ywallet splits users 50/50 sapling/orchard, which I still don’t really understand. Hoping that with QR its a clear justification to be fully in Orchard. This one can be codified but I suspect we meet any reasonable encoding here.

We can’t really codify “Sapling does < 10% of tx volume” reliably, because Zcash’s tx volumes are in the regime where 1 ZEC/day beyond covers the tx fee for all shielded traffic. (And thus could adversarially spam Sapling). However we can use judgement by looking at the graphs and seeing that it has significantly declined as a percentage of the network traffic. (With mining pools being a large part of it)

My experience with Custodians is generally that they tend to require large external pressure and assistance to upgrade. Custodian complexity also needs to be factored into most changes. However custodians getting their users quantum recoverable is already sufficient reason to put a date on going withdraw-only.

If an end date is placed that is reasonable (~1 year out), and the tooling to migrate for the most part already exists, people will adapt.

2 Likes
12

I was wondering if we should make use of the remaining ZEC in the deprecated pools to fund long-term security while honoring the 21 million supply cap.

I think we should really avoid this at all costs. For Sapling, I’m proposing making it withdraw only. Ideally, 2 years into being withdraw only Sapling remaining ZEC looks like Orchard – namely <50k ZEC. The gain then to add that to long term security budget is extremely low. I want to avoid any incentive that could even make it seem like the network would benefit from unclaimed funds – the opposite should be true. We want every ZEC to be QR and able to go untouched for decades. We just must be Quantum-recoverable first

3 Likes
13

I see your point, but it is difficult for me to imagine that anyone would deliberately make it more challenging to upgrade to post-quantum cryptography just so that a small remaining balance could benefit long-term security after a future halving.

Let’s say there is 100k ZEC left across both pools once we deprecate them. The choices as I see them are:

  1. Let the first rational actor with a cryptographically relevant quantum computer steal from the pools until the turnstile is hit, basically acting as an inflation bug.
  2. Burn the remaining pools, so that in practice we have a promise that there will only ever be 20.9M at any one time from now on.
  3. Put the funds to use. This is where I propose the most neutral and underfunded cause. No one profits from this directly, but it buys the network more time before it has to rely strictly on the fee market.
2 Likes
14

My personal thought is that (2) is better, as it also leaves optionality for more out-of-band recovery method for such funds. (E.g. knowledge of note commitment internals verifiably committed to well before Q-day, along with proof-of-knowledge of seed phrase)

1 Like
15

Good point! I hadn’t considered that.

1 Like
16

That was set back in the days when ywallet was the only working orchard wallet. Putting everything into orchard would mean that every time you made a tx to another wallet app, it would have to cross back to the sapling pool and reveal your amount.

2 Likes
17

It appears they do not work for shielded deposits quite yet. However given their intention to support Orchard they could easily handle a Sapling deprecation.

1 Like
18

Strongly oppose readiness triggers. Having worked in such large organizations, the internal incentive to change anything is exactly zero (or even negative). They will only respond to deadlines, and a well communicated deadline with reasonable time to respond creates an internal pressure to fix it on time or risk getting in trouble. This is the incentive these large orgs can understand.

1 Like
19

I support setting the withdraw-only direction early. But the date needs an execution matrix behind it.

Which wallets are Orchard QR ready, which are not, what user share sits behind each one, and what still blocks migration. That has to include multi asset wallets, YWallet, and mining payout surfaces. If that map does not exist, the date is not real.

The Orchard path is already live. The pure Rust, Zebrad based Orchard pool is already producing mainnet blocks, so shielded Orchard payouts are not hypothetical. That means the work now is wallet rollout, pool migration, and communication.

Measure QR Orchard activity after NU7. Push the biggest Sapling surfaces first.

20

Lets finish this first please. :index_pointing_up: