A private key is a sufficient condition for moving funds. Every custody model, every wallet warning label, every institutional policy in this industry rests on that one axiom. Zcash's Network Upgrade 7 proposes to break it. Under the proposal, ZEC held in the original Sprout shielded pool becomes unspendable — not because the keys were lost, not because a wallet failed, but because the protocol would decline to validate the spend. Keys intact. Balance visible. Funds immovable.
That is the entire technical content of the report in front of me. No ZIP number. No description of the freeze mechanism. No figure for how much ZEC sits in that pool. No activation height. Mainnet activation decision still pending, the item says, and stops there.
I have audited tokenomic models that were more forthcoming than this. The gap between what the proposal does and what the public knows about it is now wider than the proposal itself.
Sprout is Zcash's first shielded pool, shipped in 2016 on a ZK-SNARK construction that required a trusted setup ceremony. If any participant in that ceremony retained the toxic waste, they could forge proofs. That risk was theoretical, unquantified, and permanent. Orchard, deployed in 2022, removed the trusted setup entirely and offered stronger privacy guarantees. Retiring Sprout has been on the roadmap for years. Pool retirement is normal maintenance for a protocol that intends to live twenty years. ZEC itself carries a 21 million supply cap inherited from the Bitcoin lineage, with a Founders Reward distribution that concluded in 2020.
NU7 is the seventh network upgrade package, a bundle of ZIPs — Zcash's equivalent of BIPs or EIPs. Governance runs through the ZIP process with Electric Coin Company and the Zcash Foundation coordinating. There is no on-chain token vote. Decision authority sits with core developers and the foundations that employ them, subject to community review. The brief confirms the process is still open. It does not confirm how open.
Here is where the analysis has to start, and where the source material fails.
The proposal converts pool state into a precondition for spendability, demoting the private key from sufficient to necessary. That is a structural change to the ownership model, not a parameter tweak. Three implementation paths exist, and they are not equivalent. The protocol could reject validity proofs rooted in the old commitment tree. It could reject transactions anchored to pre-NU7 anchors. Or it could mark old pool balances unspendable at the consensus layer. The first two are recoverable — the tree survives, and a later upgrade could re-accept old anchors. The third is a burn. Without the ZIP text, an observer cannot distinguish retirement from confiscation, and that distinction is the whole ballgame. A maintenance window and an expropriation look identical from a summary paragraph.
Strip the vocabulary and the risk-register entry is plain: an administrator can render existing balances immovable. It is the same privilege that centralized custodians are criticized for holding, executed one layer lower and ratified by a ZIP. Decentralization does not eliminate that authority. It only changes who signs for it. The relevant question is not whether Zcash can freeze a pool. It is what constrains the decision to do so. Today the constraint is a review process with no published timeline and no published text. Governance isn't a vote; it's a verification. Right now there is nothing to verify.
The economics cut both ways and the market will price the wrong side first. A permanent freeze removes ZEC from circulating supply, which reads as deflationary. But the supply contraction is unquantified while the trust discount is immediate. Holders do not ask how many coins were frozen. They ask whether their coins could be next. In a drawdown, the second question prices before the first. I have watched this pattern since the 2017 ICO audits: the mechanism nobody can measure gets ignored, and the narrative everybody can repeat gets sold.
The exposure that matters is not retail. Any venue that accepted Sprout-era deposits between 2016 and 2018 and never migrated its shielded treasury now holds a balance it cannot move. That is a custody event, not a UX problem. Exchanges will discover it late, disclose it reluctantly, and their users will discover it last. Downstream adaptation is the unglamorous risk here — wallets rendering a visible-but-unspendable balance will generate support tickets that read like theft, and support tickets become withdrawal runs.
And watch the migration. Rational holders move to Orchard before activation. Every prior pool transition in this ecosystem has produced a migration wave; the only variable is whether it is voluntary. If the activation height is announced with a generous window, the migration is orderly. If it is announced short, the migration is a stampede and the order book absorbs it.
Now the contrarian reading.
The reflex will be to call this confiscation and to treat it as a scandal. I think that is the wrong diagnosis, and it lets the actual failure off the hook. Long-lived protocols must retire cryptographic assumptions; Sprout's trusted setup is a liability, and Orchard is better engineering. Pruning old anonymity sets also reduces the verification surface. Doing the hard maintenance is what a serious protocol does, and the industry should be able to say so without flinching.
The failure is procedural. A change to the spendability condition of existing balances was communicated as a one-line summary with no specification, no mechanism, and no quantity. In 2020 I templated governance proposals for a mid-sized DAO, and the first field I made mandatory was who can move the funds, and under what condition. Any proposal that alters that field for existing holders must ship with the specification attached — before the discussion opens, not after the reaction. This one did not. Skepticism is the first line of defense, but you cannot be skeptical of a document that does not exist.
Three numbers decide this. The Sprout pool balance. The activation height. The ZIP number. Until all three are published, every ZEC position carries an unpriced governance risk, and no amount of community reassurance substitutes for a specification.
Verify everything, trust nothing. Code is the only law that holds — which is exactly why the code has to be published before the law changes.