I know ZSAs can exist as standalone. But in practical terms I don’t believe one doesn’t lead to another. At a minimum people will argue we need faster finality for private stablecoin settlements. People will also say we need faster bridging to take advantage of ZSAs. And I suspect there’s a lot more complimentary aspects.
Yes. Even the best have to face reality at one point:
Your assumption is that ZSAs are not part of those expenditures and you don’t have any compelling evidence of that being so. Your arguments against ZSAs as you have presented them have little to do with ZSAs not being additions to “core privacy, UX, and adoption” but with governance risk, hard forks and market fit of a memetic slogan (encrypted bitcoin).
The hard fork risks have existed since day zero with the founder’s reward and then the dev fund and last November with the lockbox. We have gone through 7 hard forks. Also if it was for the “encrypted bitcoin” argument then the assets that should be valued around 400 usd today should be the Zcash forks that removed the “miner tax” but unsurprisingly they forked their way straight to irrelevance.
It’s completely valid to make these questions and I appreciate you have. In fact those are the ones that bitcoin developers did back then when the Zcash team proposed ZEC as a PR to their codebase and they said “too new tech” and they were correct. Although I don’t think the arguments you are providing are sufficient enough to convince me of the consequences you enumerate. Although I’m open to change my mind about it since I was not a fan of ZSAs in the beginning.
3 Likes
Created an account for the sole reason to express complete an utter agreement with the OP. ZSAs should be abandoned. The fact that a lot of work has been done already is irrelevant.
2 Likes
If Tachyon is next gen scalability and UX + privacy it would make sense to offer Tachyon ZSA’s. People will always use what is most convenient, its an opportunity.
2 Likes
A small point here, for the sake of clarity and understanding… from the link you offered, there’s a definition that agrees with what I believe the sunk cost fallacy is:
“..a sunk cost is a sum paid in the past that should no longer be relevant to decisions about the future.”
This seems to contrast with the idea of recovery of expenditures, and instead underlines a pattern of human psychological attachment to a direction or project that was previously invested in, rather than being fully rational in decision making, based only on present circumstances.
Also illustrative phrases from the article: “throwing good money after bad” vs “cutting one’s losses.”
It sounds like you are representing that ZSA proponents are in fact NOT involved in a sunk cost fallacy, but I think you have misrepresented what that term is precisely in your post.
I’m picking at this not to be overly irritating and pedantic, but because the sunk cost fallacy is a powerful cognitive trap, and it’s very possible that some people within a group are able to avoid it while others are not - so it might be worthy to highlight this point?
To avoid the sunk cost fallacy, arguments for activating ZSAs stemming from “we already spent 500k Zec” or similar should be considered completely irrelevant.
An example: I paid 10 zec to get a Taylor Swift ticket for a concert happening tonight, but I have terrible influenza, and I know I will be miserable at the show. Should I go?
Rationally, no, I should not.
Someone operating under the sunk cost fallacy might say, yes, of course, I paid for it already.
1 Like
Why Bother? : The case for ZSAs beyond the hype
If ZSAs were solely about chasing the current “DeFi” cycle or launching random meme tokens, I would agree with the scepticism. But viewing them only through that lens misses a structural failure in our current privacy model.
If we are honest with ourselves, the thought of using Zcash in the real world currently feels like wearing a bulletproof vest to a knife fight, only to be asked to take it off at the door. The issue isn’t just about moving money; it’s about the Context of Commerce.
What Leaks? : The “Data Halo” trap
Imagine you are making a transaction. Your OpSec is tight. You scan the QR code, knowing the value transfer is occurring in a cryptographic black hole. You feel that fleeting sense of triumph—you’re beating the surveillance economy. 
And then, the cashier looks up and asks:
“Can I just get your email address for the receipt?” or “Please enter your phone number to collect your points.”
In that split second, the architecture of your privacy collapses.
This is the Data Halo. It is the receipt, the warranty, the loyalty point, the ticket, and the gate code. Currently, Zcash protects the asset (the money), but the context (who you are and what you bought) is stripped naked at the point of sale.
The transaction is dark, but the interaction is lit up like a Christmas tree. 
The Fix? : Bridging the Metadata Gap
As long as this gap exists, we are forced to choose between being a ghost (using ZEC but having no perks/receipts) and being a participant (doxing ourselves).
I believe ZSAs can provide some of the missing cryptographic primitives needed to carry receipts, tickets, and reputation within the shielded pool.
This leads us to the ultimate goal: Verification Without Revelation.
Why Now? : The cost of waiting
Sure, we can leave problems on the table. All products do; prioritisation is necessary. There are times when deferring features is a good idea and times when it is not.
I fear this is a time when it is not.
11 Likes
yes ^ n
2 Likes
I’m skeptical about how realistic these examples are. Even if ZSAs provide a technical way to privately exchange that data, the merchants have no interest in giving that data up. They WANT to collect your phone/email/loyaltyID at checkout to improve their marketing strategies. I don’t see why they’d go out of their way to adopt a new technology that reduces their marketing effectiveness 
I feel like the best argument for activating ZSAs would be a list of great use-cases, ideally with some amount of proven demand.
2 Likes
Fully agree.
2 Likes
The use-case I am looking the most forward to is to bridge DAI to Zcash. I also view it as a stepping stone to eventually create a FHE-based L2 for Zcash.
The mission of Zcash is to give people economic freedom by giving people financial privacy and censorship resistance. Zcash will be severely constrained in achieving that goal if the only privacy it can provide is when holding and sending ZEC.
3 Likes
ZSAs would attract a completely different user base than Zcash’s current one, and that user base is already being served. Every major company is launching their own L1 or partnering with chains built specifically for RWAs, tokenized assets (stocks, bonds, metals, GPUs etc). They’re spending millions and billions on integrations with Blackrock, JP Morgan, Nasdaq. That’s not Zcash’s ethos, and we shouldn’t pretend it is.
Zcash is still small. We’re not in the top 3, or top 5. Before we start chasing institutional tokenization deals, we need to get people to actually use Zcash for what it’s supposed to do. Every engineering hour spent on ZSAs is an hour not spent on the fundamentals that would actually grow Zcash’s user base and make it more resilient. But the cost isn’t just engineering time. ZSAs would add significant protocol complexity, which means more attack surface, harder audits, and slower future development
I’m completely in favor of enabling powerful L2s that can serve independent use cases where ZSAs actually make sense. L2s can iterate faster, serve niche verticals without burdening the base layer, and experiment with multi-asset privacy in ways that would be risky or inappropriate for L1. People feature sets that L1 could never serve anyway. That’s the right layer for this kind of experimentation, not the protocol core.
Here’s what I think we should focus on instead:
Post-quantum cryptography. This should be near the top of our priorities. A privacy coin that gets broken by quantum computers in a decade is worthless. The cryptographic foundation is everything. Institutions are already thinking about quantum threats to long-term holdings. Getting post-quantum ready now is a competitive advantage and a signal that Zcash takes long-term security seriously. Very few chains are ahead on this. We should be one of them.
Protocol security and audits. Privacy protocols are complex and the stakes are high. We need ongoing security research, formal verification where it matters, and regular audits. A single critical vulnerability could destroy years of work and trust. This isn’t glamorous but it’s what keeps the system trustworthy.
Protocol simplification. Complexity is the enemy of security. We should streamline where we can. Remove cruft. Make the protocol easier to understand, audit, and implement. A simpler protocol is a more secure protocol, and one that attracts more developers willing to build on it. This also reduces the surface area for bugs and makes future upgrades less risky.
Network scaling and transaction optimization. Sync times, throughput, latency. These directly impact user experience and they’re not where they need to be. If Zcash is slow or painful to use, privacy doesn’t matter because people won’t use it.
Wallet infrastructure, DevX, and node accessibility. We need to continuously improve the experience of both building for Zcash and holding Zcash. On the development side, we’re moving in the right direction. Better SDKs, better documentation, more accessible tooling. This work is already enabling more builders to create wallets, explorers, gifting apps, light clients, and other software for Zcash. We should double down on this momentum. On the user side, the goal remains the same: holding Zcash shouldn’t require technical sophistication. Better and private light clients that sync in seconds. Easier node operation. More HWs integrations. The infrastructure should support everyday users at every level.
Shielded multisig. This is table stakes for serious custody and inheritance planning. You can’t hold significant amounts of Zcash properly without it. It’s not flashy, but without it, a whole category of users and use cases remains blocked. This matters, but it’s a specific unlock, not a foundational priority.
3 Likes
That’s an opinion, and I fundamentally disagree with it.
A protocol like Zcash provides a consensus and ordering mechanism (L0), and a distributed economic computation (L1).
Scale needs to be addressed at both L0 and L1. If you have slow L0 latency then any attempt to speed things up at higher layers is hopeless. Aggregation is not enough; that might be sufficient to address bandwidth, but not latency. Roll-ups that operate without support from L1 result in a walled garden that does not interoperate properly with the L1 token, especially when privacy is a requirement.
Modularity needs to be addressed at L1 at a minimum, but possibly also at L0 and higher layers.
For features, it really depends on the feature. But Zcash Shielded Assets naturally belong at L1, because ZSA notes can’t be indistinguishable from ZEC notes otherwise, and as I’ve said, that is a critical property to maximize note traceability sets.
I agree with all of your other priorities. None of them are incompatible with or even particularly complicated by ZSAs. Yes there’s an engineering bandwidth trade-off to be made. I think you’re overestimating the cost of merging ZSAs. The code is right there, feature-flagged, on a branch. We have essentially a one-time opportunity to merge it before it bitrots.
9 Likes
I think that’s poorly worded and will result in concluding in many cases that people are committing a “sunk cost fallacy”, when actually they are just valuing things differently to you.
Life isn’t like chess or Go, where it’s provable that optimal strategies do not depend on history other than the current board position. It’s a continuous hidden-information “game” in which the “players” have reputations, remember what has happened, and are legitimately invested in their efforts having permanent effects on the world.
In particular, if you abandon projects that people have put significant work into, you will piss them off, and they will be right to be pissed off. You will get a reputation for abandoning projects and no-one will work with you.
I know what the economic rationalists would say about this. They would say that you should value reputation changes as a future benefit or cost as though they were monetary. Hear my exasperated sigh. Those are not fungible types of value.
Really, just deal with the fact that people often use the past cost as a heuristic estimate for the future value. It will be fine, I promise. If you think they overpaid and they do not, then with your definition you will think they are committing a sunk cost fallacy, when actually they’re just disagreeing with you about the future value.
3 Likes
That sentence in my post should be disregarded. It doesn’t reflect what I meant. What I should have said is that L2s serve a different purpose in the ecosystem: block time, block size, programmability, gas currency, fees, core functionalities (ex: payments) etc. This is true whether we’re talking about Lightning for Bitcoin or Base for Ethereum.
I disagree that ZSAs naturally belong at L1. Why should they share a privacy pool with ZEC notes? Just as we have separate shielded pools today, it’s reasonable to have separate pools for each ZSA. Making ZSA notes indistinguishable from ZEC notes is a mistake. Many Zcash holders already worry about an infinite mint bug, and they don’t want additional risk vectors. The FUD we’d have to fight by making ZSA notes indistinguishable from ZEC would be immense.
I see Zcash as a store of value and digital cash, not as a neutral network for moving any kind of asset indistinguishably.
I think merging now is premature. There should be clear consensus before moving forward, and many Zcashers, myself included, disapprove of ZSAs on L1.
You shouldn’t go because you will give other people influenza, which spreads like wildfire in tightly packed theatres with almost no-one masking. That aside: why are you trying to tell people how to make personal choices? They can do what they like, as long as it doesn’t harm others. This is actually a really interesting example because going to the concert potentially does harm others. As an anarchist, I personally think that’s the only relevant factor other than “do you want to?” You can perfectly well choose to use the amount you paid as an input to deciding whether you want to. Please don’t try to impose rational choice theory where it doesn’t matter!
Absolutely not, because this would have terrible privacy. The note traceability sets of individual ZSAs are too small.
5 Likes
its great that you joined 2 days ago, but as others noted the ZSA debate was had years ago. and basically all of the building has already happened, so ZSA is a feature that will happen within a year or two. there really isnt a community debate anymore its strange that the mods didnt close this thread up already tbh this is like opening up an opposing view about the lockbox
1 Like
If someone were bootstrapping a new chain for this exact purpose, they’d start from scratch. I don’t understand why we’re optimizing Zcash for ZSAs.
2 Likes
Zcash is optimizing for mainstream tx load, and whether thats primitive txs or ZSAs doesnt really matter because the optimization solution treats them without discretion