Zcash does not have 1 private side. It has four, built in sequence, and two of them have been closed to incoming value while two remain open. Each was introduced to fix something the one before it got wrong, and none of the earlier ones could simply be switched off once funds were sitting inside.
That sequence explains almost everything a reader finds confusing here, including why documentation written in different years describes different things without either version being wrong.
The place to start is what a pool actually is, because it is not the thing most people assume, and because getting it wrong makes every later paragraph read as a contradiction.
A pool vs an address type
The commonest confusion in this subject is worth clearing before anything else, because almost every other question depends on it. An address type is what you hand to someone who wants to pay you. A pool is where the value sits once they have. Two different lists, two different questions.
They are related but they are different lists, and conflating them makes the rest of this incomprehensible. Our guide to Zcash address types covers the first list. What follows covers the second.
The distinction is not pedantry, and the evidence is that the writing on this subject skips it. The most-linked editorial explainer of the Sapling upgrade never uses the word pool at all (source: Coin Bureau), describing an upgrade to a system rather than a container that holds value. A reader who learns the subject from those pages arrives with one list where there are two.
A pool, more precisely, is a set of records the chain maintains for one shielded protocol: the commitments created by that protocol's transactions, the spent markers it has published, and a running total of how much value it holds. Our guide to how unspent outputs hold value covers the container model these records replace on a transparent chain.
The analogy that transfers best is not from privacy at all. Bitcoin carries several address and script formats simultaneously, each introduced by an upgrade, none retired, because coins sit in the old ones and nobody can move them for their owners. Our guide to legacy, SegWit and Taproot describes exactly that situation. Zcash has the same problem with a sharper edge, because its old formats go beyond inconvenient into cryptographically distinct systems.
So the question is not why Zcash has four pools. It is why any chain that keeps upgrading a privacy system ends up with more than one.
Sprout, and why it is closed
Sprout is the original shielded pool. It shipped with the chain in 2016 and carried the first working implementation of the idea Zcash exists to demonstrate, which at the time nobody had deployed anywhere. Its limitations are the reason the other two exist.
It was also slow and heavy in ways that made it impractical for most people. The design that replaced it was not an optimization; it was a rebuild, which is why the two do not interoperate and why Sprout could not simply be upgraded in place.
What matters now is that Sprout is closed, and closed by consensus rather than by convention. The rule that did it blocks any increase in that pool's balance, and its own specification frames the change as groundwork for retiring the protocol rather than as an end in itself (source: Zcash Improvement Proposals).
Read the scope of that carefully, because it is narrower than "Sprout is dead". Value cannot enter the pool from outside. Movement between two parties already holding inside it is a different case and is not what the rule addresses. In practice this means a Sprout address is not something anyone should be handed as a way to be paid, while funds already sitting there are not frozen.
The distinction matters because the two readings lead to opposite advice. Read as "the pool is dead", it implies urgency and loss. Read as written, it says the entrance is shut and the room is intact, which is a reason to plan an exit rather than to panic about one. The specification's own framing supports the second reading, since it treats the rule as groundwork rather than as the removal itself.
The reason the rule exists at all is the second thing worth knowing, and it is the same reason the next section is about a migration rather than an upgrade.
Sapling, and the migration every holder had to make
Sapling arrived in 2018 and it is the reason shielded transactions became usable on ordinary hardware rather than on a workstation with gigabytes to spare. That much is well covered elsewhere, and it is the part of the pool story most readers already know.
What they do not describe is the problem it created. Funds sat in Sprout. Sapling was a different system. Somebody had to move them, and moving them was not a normal transaction.
The project's own documentation is blunt about the mechanics, and the detail most summaries miss is that there were two paths rather than one. The standard payment tools prohibited sending directly from a Sprout address to a Sapling one, so users of those tools "must use a transparent address as an intermediary which will obviously expose the balance being migrated". But the consensus rules themselves permitted a direct Sprout-to-Sapling transaction, and "a migration tool is available to make use of this consensus level mechanism" (source: Zcash documentation).
Read what the tool actually bought, because it is easy to overstate. Both routes exposed the amount: the consensus path required the balance to pass through the transparent value pool, "thus exposing the value without a transparent address". What the tool protected was identity rather than quantity. Its own documentation says that "since the exposure of the migrated amount potentially compromises the privacy of users, the tool works by hiding individual migration transactions among those of all users that are doing the migration at around the same time".
So leaving a closing pool cost the amount either way, and the best available mitigation was to be one of many people leaving at once. That is the shape of every pool migration since, and it is why a pool being closed matters to anyone still inside it.
A caveat on that source. That documentation set has produced incorrect protocol claims before, so every figure taken from it here is corroborated against the consensus specifications cited alongside it, and anything that could not be corroborated was left out.
Which brings us to the pool that replaced it, and to the one that has since replaced that.
Orchard, and what actually changed
Orchard arrived in 2022 as Sapling's successor, and it is the shielded protocol the two newest pools are built on. Its specification carries the title "Orchard Shielded Protocol" and the status Final (source: Zcash Improvement Proposals), which settles what it is but not, as the next paragraph explains, whether it is running.
A word of caution on reading those status fields, because it trips almost everyone up on first reading. They describe the state of the document, not the state of the network. Whether something is running is a question for the chain rather than for the index.
It differs from Sapling in ways that matter more to implementers than to holders, which is why summaries of it tend to be either very short or very technical. The consequence a reader can act on is narrower: Orchard has no address of its own. Being paid into it requires a unified address, which is one reason those exist.
What Orchard changed, in terms a holder can act on, is narrower than its engineering reputation suggests. The proofs got cheaper to make and no longer needed the setup ceremony Sapling relied on. For someone holding coins, the visible consequence was that it has no address of its own: being paid into Orchard requires a unified address, which is one reason those exist and one more place where the pool question and the address question come apart.
Each of these arrivals came through a network upgrade that every participant had to adopt, which is a mechanism worth understanding on its own: our guide to how chain upgrades work covers what has to happen for a change like this to take effect at all.
And then the pool was superseded, which is the part most writing on this subject has not caught up with.
Ironwood, and what closed the Orchard pool
The newest pool is weeks old at the time of writing, and its arrival moved where new value goes. On July 28, 2026, at block height 3,428,143, the Ironwood upgrade activated on mainnet, and the pool that had been the default since 2022 stopped accepting deposits.
The project's own upgrade page states the consequence plainly: "the original Orchard pool is now restricted, and funds exiting Orchard must pass through Zcash's turnstile to enter Ironwood" (source: Zcash). At consensus level the rule is the familiar one in a new place: no new value may enter the Orchard pool.
You can watch that boundary in the open, which is the useful part: our guide to reading what actually landed on chain covers the habit, and pool balances are among the things a public explorer will show you.
Ironwood is a fourth pool and it is not a fourth protocol, a distinction that can produce two contradictory readings from the same source in a single sitting. The specification introducing it calls it "an Orchard-protocol successor to the Orchard pool" (source: Zcash Improvement Proposals), added for quantum recoverability and with supply integrity supported from the start. One protocol, two pools using it, and the newer one is where value now goes.
So the pattern that produced Sapling has now run twice more. A pool is opened, it becomes the destination, the previous one is closed to new value, and whatever sits in the old one has to be moved deliberately or left.
Orchard also had a serious incident in 2026. A reviewer identified a soundness problem, and the network switched the pool off until a corrected version was deployed. That episode has its own article and this one does not retell it; the relevant point here is that a pool can be paused by consensus and later resumed, which is a property of the design rather than an accident.
One thing about Orchard did not change, and it is why the section after this applies across the whole set. It remains a shielded pool in the same sense every other one is: a set of commitments, a set of spent markers, and a total. The improvements are in how the proofs are built and what they cost, not in what the pool is. That continuity is why the audit property described next applies identically to every one of them.
So four pools, in order, each answering the last. What makes the arrangement tractable is the thing none of the measured pages mentions.
The value balance: how anyone can audit a private system
Here is the part that surprises people, and it is the reason a private system can still be audited from the outside. The project's own documentation sets it out, and it is quoted below.
A shielded pool hides individual transactions. It does not hide how much value it holds in total. The chain maintains a running balance for each pool, and that balance is public.
That single design decision is what makes a private currency auditable. The documentation states the problem directly: because of the privacy properties of shielded addresses, "direct auditing of the total monetary supply is impossible", so a mechanism exists to monitor value entering and leaving each pool. The same page supplies that phrasing, and the caveat above applies to it; what makes the claim safe to repeat is that consensus enforces the stronger version, below.
At consensus level the guarantee is stronger than monitoring. Blocks that would produce negative shielded chain value pool balances, or push total supply beyond the protocol maximum, are prohibited outright (source: Zcash Improvement Proposals). A pool cannot pay out more than it took in, and a block attempting it is invalid rather than merely suspicious.
The figures themselves sit in plain sight. Each pool's change in value travels in the transaction as an ordinary signed integer, not as ciphertext (source: Zcash Improvement Proposals), which is why anyone running a node can total the balances without special access.
The result is unusual and worth naming. Anyone can verify that no coins have been counterfeited inside a system where nobody can see individual payments. Our guide to proving reserves without revealing everything covers the same tension in a different setting, and our guide to why a fixed supply must be checkable covers why anyone should care.
Which leaves the cost of running several of these at once.
What having several pools costs
The arrangement is defensible and it is not free. Four consequences follow from carrying several pools at once, and they land on different people: the first affects users directly, the second affects anyone still holding in the oldest pool, and the last two affect anyone trying to learn the subject.
Your privacy set is divided. A shielded payment hides among the others in its own pool, not among every shielded payment ever made. Four pools means four smaller crowds rather than one large one, and a pool opened weeks ago is the smallest crowd of all. Our guide to whether Zcash transactions can be traced covers what that means in practice.
That division is a real cost and it is rarely priced in. A second editorial explainer of the same upgrade mentions Orchard exactly once across roughly thirteen thousand characters (source: Blockonomi), so a reader learning from those pages would not know that pool exists, let alone that two more have been opened since or that their own payments hide in a crowd smaller than the chain's total.
Value stranded in an old pool is awkward to move. The Sprout case showed the pattern: leaving a wound-down pool cost the privacy of the amount being moved. Anyone still holding there faces the same trade today.
Software has to support all of them. The keys involved differ by pool, and our guide to what a key pair actually does covers why that is not a detail an application can paper over. A wallet that handles Orchard well may handle Sprout not at all, and support for the oldest pool thins as it is wound down. This is an article-time fact and it moves, so confirm it against your own software rather than any list.
Explanations date badly. Writing from 2018 describes a two-pool world accurately and is now describing history. The project's own engineering post on Sapling transaction structure is dated October 2018 and opens with the activation still approaching (source: Electric Coin Co.), which is exactly right for its moment and no guide to the present. That is the failure mode to watch for in any pool explanation: it is not wrong, it is old, and nothing in it says so.
None of those four costs is an argument against the design. They are the price of upgrading a privacy system without confiscating what people already hold, and the alternative to paying it is a chain that either never improves its cryptography or strands the people who trusted the old version. Seen that way, three pools is what responsibility looks like from the outside.
The design that avoids all four is a chain with one pool and no choice, which is a different set of trade-offs rather than a better one. Our guide to how Monero works describes that alternative, and our guide to privacy on a public ledger covers the habits that matter whichever design you use.
From where BloFin sits, one practical note. Withdrawing to a shielded address puts value into whichever pool your wallet supports, and that choice is made by software rather than by you. It is worth knowing which pool you have landed in, because the answer determines what a later move will cost.
How to tell which pool your funds are in
The question matters because it decides whether your wallet can spend the balance at all, and because a pool that has been closed behind a one-way gate behaves differently from one that is still open.
Your wallet is the first place to look, and on modern software it is usually the only place you need to. A wallet that supports the current pool will normally show a single balance and handle the distinction internally. A wallet that shows more than one shielded balance is telling you, without saying so, that it is holding funds in more than one pool.
The address you were paid into is the second clue and a more reliable one. An older shielded address can only receive into the pool that address belongs to, so funds received at it sit in that pool regardless of what your wallet displays. A unified address defers the choice to the sender's software, which is exactly why the newer format exists.
The behavior on send is the third, and it is definitive. If a wallet refuses to spend a balance, or offers to move it before spending it, the funds are in a pool that the current rules no longer allow to be spent directly. That prompt is the migration step rather than an error, and taking it is the whole remedy.
What none of those three tells you is anything about the recipient's side. Both ends have to be able to handle the pool in use, and the sending wallet picks whichever option both support. That is why a payment can succeed from a fully modern wallet and still land in an older pool: the recipient's software offered nothing better.
Frequently asked questions
How many shielded pools does Zcash have?
Four, on three distinct protocols. Sprout from 2016, Sapling from 2018, Orchard from 2022, and Ironwood, which activated in July 2026 as a successor pool on the Orchard protocol rather than as a protocol of its own. That is why published counts disagree: some writers count pools and some count protocols. Two of the four are closed to incoming value, Sprout and Orchard, each shut by its own consensus rule. Sapling and Ironwood both still accept it, and the specification that would close Sapling has been reserved rather than written.
Can I still access funds in the Sprout pool?
Funds already there are not frozen and the keys still work. What changed is that value cannot enter from outside, so a Sprout address is no longer something to hand out to be paid on. Moving funds out exposes the amount whichever route you take, because the balance passes through the transparent value pool on the way. The migration tool reduced the harm by batching many users together rather than by concealing sums. Waiting does not improve the trade, since support for the oldest pool thins rather than grows.
Why can anyone see how much is in a shielded pool?
Because the alternative is a currency nobody can audit. Individual shielded transactions reveal nothing, which means the usual method of confirming that no coins were counterfeited, adding up every payment, is unavailable. Publishing a running total per pool restores that check without revealing anything about who holds what. Consensus rules then enforce it: a block that would drive a pool balance negative is invalid, so the pool cannot pay out more than it received.
Does moving between pools reveal anything?
It reveals the amount. Value moving from one shielded pool to another changes both pools' published balances, and the size of the change is the size of the transfer. The individual transaction stays private in every other respect, but the quantity is visible to anyone watching the totals. This is the direct consequence of the auditability described above, and it is the clearest example of a privacy system trading one property to secure another.
Which pool am I using right now?
Whichever one your wallet chose, which is usually the newest it supports. Software updated for the July 2026 upgrade directs new value to Ironwood; software that predates it will reach Orchard or Sapling instead, and Orchard no longer accepts incoming funds. The practical way to find out is to check what your wallet reports rather than to infer it from the address you were handed, because a unified address deliberately does not disclose what is inside it until a payment is made.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository. All facts independently verified against cited documentation current as of August 2026. Which pools a given wallet supports is an article-time fact that changes, so confirm the current position with your own software rather than relying on any list, including this one.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Regulatory treatment of privacy assets differs by jurisdiction and changes over time. Do your own research before making any decision.