str4d
September 21, 2025, 7:16pm
3
This idea (and variants thereof) has been proposed several times in the past for Zcash. A few examples I could easily find:
opened 06:05AM - 18 Nov 18 UTC
D-economics
D-bitcoin-divergence
F-tx-fees
Currently there is a fee for sending a transaction, but after that all full node… s are required to store your transaction outputs forever at no further cost to you.
Utxos and shielded pools impose several kinds of negative externalities on all users of the network:
1. They increase storage costs that all full-nodes and miners must pay. This is clear if you think like an attacker and use it as a DoS vector: at low cost to you, you can impose a permanent increase in resource requirements on your targets (full-nodes and miners). Another way to look at this is that we need a kind of garbage collection (of obsolete read-only shielded pools and unloved utxos) in order to allow better scaling.
2. Keeping old utxos and old shielded pools around requires maintaining — live in the current product — the protocols and source code to accept them. This increases complexity of the protocols and code, which imposes an increased risk of catastrophic security failure, which risk is borne by all users.
3. The effort to maintain the protocols and code to handle old utxos and old notes use up development resources, thus slowing down development of new improvements and increasing the risk of security failure (additionally to the above-mentioned risk in 2).
4. Old utxos and old shielded pools add uncertainty about the true size of the monetary base, which prevents using Zcash as a unit of account and adds uncertainty to investment decisions. Again, this cost is borne by all users.
5. Old shielded pools induce uncertainty about whether counterfeiting occurred in the past. Counterfeiting doesn't represent an economic cost to all other users (since we have a [policy](https://z.cash/blog/defense-against-counterfeiting-in-shielded-pools/) against it being allowed to expand the size of the monetary base), but _uncertainty_ about whether an old shielded pool will turn out to have been counterfeited still imposes a substantial cost on all users by increasing FUD about Zcash's security. As the amount of ZEC in an old shielded pool goes down, the degree of FUD about it also goes down, and when the old shielded pool is completely empty then we know no counterfeiting occurred.
I propose a minimal initial step which, while it won't solve all of these problems, gets us closer to solving them in future network upgrades. It is to institute a fee for maintenance of utxos and notes.
The mechanism would simply be that the consensus rules require an additional amount of txfee, determined by the age of the state that is needed.
The fee policy in Blossom would be extremely simple. The goals for Blossom are just to implement the mechanism, establish the social norms, and see how much a minimal fee motivates people to act. I propose: if the utxo or shielded pool you are spending from is less than a year old, then no additional storage fee. If it is more than a year old, then the additional storage fee is 1 zatoshi per block that the utxo or shielded pool has existed.
In addition to the general policy that storage is free for the first year, we should grandfather-in the current shielded pool so that people have twelve months to move their notes from the current shielded pool (which is the second shielded pool — the one created by the activation of Sapling) to the [third shielded pool](https://github.com/zcash/zcash/issues/3667) at no charge.
(This really underscores why I'm eager to get this change into Blossom — it is going to take years to have its effects.)
The additional storage fee just goes to the same place that the txn fee goes (to the miner).
Here's a related paper:
http://fc18.ifca.ai/bitcoin/papers/bitcoin18-final18.pdf
In parallel with this ticket (implementating the mechanism and instituting the simple policy outlined here), we should ask researchers in computer security, economics, etc to analyze this system and propose a method of pricing this. But we should absolutely *not* delay adopting the simple first version while that research is in progress, as it is likely to take years.
opened 12:19AM - 03 Mar 21 UTC
Dropping this issue here as a discussion rallying point about "Pool Lifecycles".… Brief overview:
The idea of "Pool Lifecycles" is to introduce a _standard and consistent_ approach to phasing out older pools. By following a consistent transition between well-named states along some sort of expected timelines, users can anticipate and prepare for pool migrations better.
We've historically often only referred to funds stored in Sprout or Sapling addresses as "in pools" and we often might say "shielded pools". However, for this ticket, we use the term "pool" to include funds stored in t-addrs. In this conception all funds exist in exactly one pool at any time, and proposals need to account for the "transparent pool" lifecycle as well as existing "shielded pools" and any other kind of pool introduced in future upgrades.
The net benefits are:
- older pools present an ongoing security risk to the entire network, including all users and infrastructure operators (this is only partially and imperfectly mitigated by the turnstile design).
- older pools require an ongoing technical maintenance burden by developers, full nodes (including miners), and others.
By retiring them over time, users, developers, and the whole network generally benefits. However, it is important to note the class of users that pool retirement will impede:
- depending on the Pool Lifecycle design specifics, long term cold storage use cases may be impeded or prevented.
The obvious first candidate for pool retirement is Sprout, which was the first shielded pool, used two different proving systems so far in its lifetime, suffered from a known counterfeiting vulnerability with no yet-known compromise, and which is too inefficient to work on mobile shielded wallets.
Note there is a zcash community dev discord room for this topic.
**Edit 2021-03-09:** Dropped "shielded" in describing pools, then added paragraph redefining "pool" to encompass t-addr funds and to assert that all funds live in exactly one pool as a basic property of pools. (This should address https://github.com/zcash/zips/issues/452#issuecomment-789499087 )
(the second one links to a specific example proposal, within the broader issue).
I think I might have also mentioned it here:
Hi!
New Shielded Dialogues Episode #5 - now on YouTube, iTunes and Spotify.
This episode covers a spicy discussion between @str4d and @shielded-nate , hosted by @aquietinvestor live from the 2025 Prague Z|ECC summit, about whether the transparent Zcash pool should be deprecated.
They delve into the technical challenges, privacy implications, and potential impacts on the Zcash ecosystem if the transparent pool were phased out. They also address the quantum computing threat to long-term storage…
If we wanted to implement this on-chain, the idea as applied to Zcash would effectively be:
A pool is deprecated and a timeline is set.
A Network Upgrade deploys consensus enforcement of the deprecation.
At at defined point after the NU, the amount you can withdraw from the deprecated pool starts decreasing at some consensus-defined rate (corresponding to an increasing “legacy storage fee”).
This could be implemented as “amount X leaves the deprecated pool, amount X*fee_ratio is removed from circulation via the NSM, amount X*(1-fee_ratio) enters a non-deprecated pool”.
Once the “legacy storage fee” reaches 100%, everyone knows that no more funds can be withdrawn from the deprecated pool (because every transaction that did so would incur a 100% fee). At that moment, the consensus rules:
Start enforcing that new transactions do not involve the deprecated pool (which “turns off” usage of the pool).
Treat the remaining value contained in the deprecated pool as entirely “legacy storage fee”.
With the above implementation of per-tx fees, this would mean removing the remaining value in the deprecated pool from circulation via the NSM.
Once the above process completes, the deprecated pool’s protocol would no longer be part of the Zcash protocol and security surface, and full node implementations could remove the deprecated pool’s code from their implementations.
11 Likes