Zcash Shielded Assets do not exist. There are 3 published specifications describing them in considerable detail, every one of which carries the status Draft, and the reference implementation of the protocol they propose to extend contains no trace whatsoever of any of it.
That deserves stating in the opening paragraph rather than buried three sections down, because the design is discussed in the present tense often enough that a reader could arrive here entirely reasonably believing the opposite, and the correction is the single most useful thing this page has to offer.
what follows covers what the three proposals would do if deployed, and what the documentary record establishes about their present state. Our guide to Zcash shielded pools covers the shielded pools they are designed to build upon.
What the three proposals would do
The proposal set divides the work across three separate documents, each of which carries a distinct responsibility within the design and each of which depends upon at least one of the others, in ways that their own texts spell out explicitly rather than leaving to inference.
ZIP 227 defines issuance while ZIP 226 defines transfer and burn, and between them the two describe what their own abstracts call the OrchardZSA protocol, characterized as "an extension of the Orchard protocol that enables the issuance, transfer and burn of custom Assets on the Zcash chain".
Read the capability rather than the mechanism and the ambition is clear. Assets other than ZEC, issued on Zcash and moving through the same shielded machinery, which would mean a token whose transfers carry the privacy properties covered in our crypto privacy basics guide rather than the transparency most chains offer.
ZIP 228 supplies the third piece of the design. It introduces asset swaps, which its own motivation section frames as simplifying the process of trading assets within the ecosystem while lowering the reliance participants would otherwise place upon centralized venues. Our guide to Zcash ecosystem and where to spend covers what swapping actually looks like today, which is a different thing entirely.
All three of them carry the status Draft. ZIP 226 and ZIP 227 were created on May 1, 2022. ZIP 228's creation date field has never been filled in and reads TBD.
The design work was produced by a named cryptography firm, which lists the protocol and the swap design among its projects (source: QEDIT). This is a serious body of engineering rather than a sketch, which is precisely why its state is worth reporting accurately.
The dependency chain, and where it breaks
The three documents emphatically do not stand alone, and it is their own texts rather than any outside reading that establishes the dependencies running between them (source: ZIP 227). The chain of dependency runs in a single direction and terminates somewhere a reader would not anticipate.
ZIP 227 states that it "must only be implemented in conjunction with ZIP 226", which makes issuance and transfer a single deliverable rather than two. ZIP 228 in turn "builds on top of ZIP 227 and ZIP 226".
So far that constitutes entirely ordinary engineering practice: a base protocol, followed by an application constructed on top of it. The interesting part is a fourth dependency, declared in the same sentence of ZIP 228, which states that the proposal "uses the transaction format encoding described in ZIP 230".
ZIP 230 is Withdrawn. The specification index lists it under that status and its title there reads "Withdrawn Version 6 Transaction Format", a detail our guide to Zcash roadmap nu7 and ironwood established while examining a different question.
So the swaps proposal depends for its transaction encoding on a document its own repository has withdrawn. None of that makes the swaps proposal wrong in itself, and reworking an encoding dependency is a routine piece of specification maintenance. It does mean that the third of the three currently rests upon something the repository has taken away, and any reader attempting to assess how close any of this sits to shipping should be aware of it.
Our guide to Zcash roadmap nu7 and ironwood covers what a status label does and does not tell you about the network, which is the necessary caution before drawing anything from a word like Withdrawn.
Four years, and what the code says
Two of the three specifications have carried the status Draft since May 2022, which is a fact about documents rather than about software and, taken on its own, a fairly weak signal about anything. Consensus work is slow by design and a long-lived draft may well be under continuous revision throughout.
The considerably stronger evidence sits in the implementation rather than in the documents, and checking it takes a single page load and about thirty seconds of attention. Our explainer on how UTXOs work covers the accounting model any asset extension would have to fit into.
The protocol these proposals extend is implemented in a Rust crate that the whole ecosystem builds on. Its current released version's top-level API documentation contains zero occurrences of ZSA, asset, Asset or issuance (source: docs.rs).
That is not a gap in coverage. A proposal adding custom assets to a protocol would appear in that protocol's public interface as types and operations for creating and moving them, and there are none. The capability is absent from the code rather than merely unreleased.
Whether a change of this magnitude could arrive without a network upgrade is worth asking, and the answer is no: consensus changes are what network forks are made of, and our guide to Zcash governance and zips covers the process that would have to carry one.
A third check confirms the position from the governance side. Whatever the specification index currently proposes as candidate material for the coming consensus change, none of ZIP 226, ZIP 227 or ZIP 228 is anywhere among it (source: Zcash Improvement Proposals). Whatever is being considered for the next consensus change, this is not among it.
Three independent checks. They are drawn from three entirely different kinds of source, and every one of them agrees with the other two. The discussion threads attached to the proposals in the specification repository remain the place where any change to that position would first become visible (source: zcash/zips).
Orchard, and what July 2026 changed
Here is the fact that makes the current position genuinely awkward rather than merely slow, and it requires stating with a degree of care, because the conclusion a reader arrives at immediately is not one that the available documents will actually support.
All three proposals extend Orchard, by their own description. On July 28, 2026 the Ironwood upgrade sealed the Orchard pool to new inflows, and three weeks later roughly 80% of the value it had held had migrated out (source: Zcash Community Forum). Our guide to Zcash quantum recoverability covers what that upgrade actually did. Whether shielded assets would trade like anything a reader has used before is a separate question again, and our comparison of spot and perpetual markets covers the vocabulary the swaps proposal borrows.
A proposal set extending a pool that no longer accepts new outputs is in an unusual position. this guide does not conclude that the sealing invalidates the proposals, and the reason for that restraint is specific rather than diplomatic.
ZIP 2005, the specification governing the current pool, refers directly to recovering "notes created according to the ZSA extension to the Orchard protocol ... if that were deployed" (source: ZIP 2005). That is a document written for the pool that replaced Orchard, published in the current specification set, contemplating ZSA deployment as a live possibility.
So the honest position is two facts in tension and no resolution published anywhere. The proposals name a sealed pool. The current specification still treats them as deployable. Nothing available says which of those two considerations governs, and any page resolving it on your behalf has gone beyond what the documents will carry.
What ZSA is today
It is not a feature of Zcash in any sense whatsoever. Nothing described anywhere above can currently be used, tested on mainnet or indeed held by anybody at all. The three independent checks assembled here converge on precisely that conclusion from three entirely separate directions (source: Zcash Improvement Proposals).
It is not a private stablecoin, or any other named product. The specifications describe a mechanism for custom assets and name no asset and no issuer of any use case beyond the general one. Whatever a conference presentation or a roadmap graphic may previously have shown you, these documents describe a capability rather than any particular thing constructed with it.
It is not scheduled. Not one of the three is among the candidate material for the coming consensus change. Two have carried Draft since 2022, and the third has never had a creation date entered at all. Our guide to Zcash roadmap nu7 and ironwood covers why none of that predicts anything either way.
It is not what makes swaps possible today. Routes for exchanging into and out of ZEC exist and are documented, which our guide to Zcash ecosystem and where to spend covers in detail, and not one of them uses any part of this design. A specification describing swaps is not itself a swap, and the distinction is the whole subject of this article.
And it is not evidence about the asset. A capability that a protocol might one day gain is not a property it has, and our portfolio basics guide covers the difference between what something is and what it might become. Verifying what the chain actually does today is what a block explorer is for.
Specified, implemented, activated: three different states
Most confusion about this subject dissolves once these three are held apart, because a proposal moves through them separately and the vocabulary does not distinguish them.
Specified means a document exists describing what the change would do, in enough detail for somebody to build it. A specification can be complete, reviewed and stable while nothing anywhere runs it. Its status field describes the document's editorial maturity rather than the network.
Implemented means code exists in at least one node implementation that enforces the described rules. This is a separate milestone requiring separate work, and a specification can sit finished for years without it.
Activated means the consensus rules are in force from a particular block height. Every validating implementation enforces them, and the chain rejects blocks that violate them. This is the only one of the three that changes what the network does.
A change described as coming can be in any of the three states, and the word carries no information about which. That is why a claim about this proposal set needs the state attached before it means anything at all.
What would have to happen for shielded assets to exist
Four steps, in order, and none of them has a published date.
The dependency question has to resolve. The proposals build on a pool arrangement that has since changed shape, and specifications written against the earlier arrangement need reconciling with the current one before implementation is meaningful.
The specifications have to reach a settled state. Documents in draft can change materially, and building against a moving target wastes the work.
An implementation has to exist and be reviewed. Consensus code carrying a new asset type is a substantial piece of engineering with a substantial review burden, because a defect here would be a defect in the supply accounting of every asset the mechanism carries.
And an upgrade has to be scheduled and activated. That requires the same coordination every consensus change requires: a height, implementations shipped in advance, then operators who upgrade in time.
Nothing in the record establishes a timetable for any of the four, and no page can supply one that the documents do not.
Why the dependency broke, and what that changes
The proposal set was written against a pool arrangement that has since been replaced, and that single fact explains most of the current state.
A specification for a new asset type has to say precisely where those assets live and how their supply is accounted for. That means naming the pool, its rules, plus the mechanism that tracks value entering and leaving it. Those references are load-bearing rather than decorative: change the pool and the specification no longer describes anything that exists.
The pool arrangement did change, in an upgrade that closed the previous one behind a one-way gate and moved the network onto a successor. Whatever the merits of that change, its effect on these documents was to leave them describing a target that is no longer current.
Three things follow, and none of them is a judgment about the proposals.
Reconciliation has to happen before implementation is meaningful. Writing consensus code against a specification whose foundation moved produces code that enforces the wrong rules, which is the most expensive kind of mistake to make in this area.
The reconciliation is not obviously mechanical. Whether the new pool's structure supports the same accounting the proposals assumed is a real technical question, and the documents do not answer it because they were written first.
And no date attaches to any of it. That is not evasion; it is the honest state of a set of documents whose dependency changed underneath them.
Anyone assessing this subject should therefore separate two questions that get merged constantly. Whether the design is sound is one question, and the record suggests careful work. Whether anything runs is a different question, and the answer today is that nothing does.
Reading a draft specification without over-reading it
Documents in this state invite two opposing errors, both of which are avoidable by attending to what the text commits to rather than to what it merely describes.
A specification describes a mechanism in normative language because that is the register the format requires, not because anything implements it. Words like MUST and SHALL constrain a conforming implementation, and where no conforming implementation exists they constrain nothing. Interpreting normative language as evidence of deployment is the first error, and it is substantially the more prevalent of the two.
The second error runs in the opposite direction. An unshipped draft is frequently dismissed as insubstantial, when a complete specification in fact represents considerable design work whose technical content can be evaluated on its merits independently of whether any implementation materializes. Draft status characterizes position within an editorial process rather than technical quality.
The reliable discipline is to hold four questions separate when reading any document of this kind: what mechanism it specifies, what external dependencies that specification assumes, what editorial status the document itself carries, and whether any implementation anywhere enforces it. Those four questions have independent answers, and collapsing any two of them generates precisely the misstatements this subject attracts.
Applied to this proposal set, the answers are that the mechanism is fully specified, its principal dependency has since been superseded, the documents remain in draft, and no implementation enforces any part of it. That constitutes a precise characterization rather than either an endorsement or a dismissal.
Frequently asked questions
Are Zcash Shielded Assets live?
No. Three specifications describe them, ZIP 226 for transfer and burn, ZIP 227 for issuance and ZIP 228 for swaps. All three carry the status Draft. The reference implementation of the protocol they extend contains no asset or issuance interface in its current release, and not one of the three sits among the candidate material the specification index proposes for the coming consensus change. Three independent checks, all in agreement.
What would ZSA allow?
Assets other than ZEC issued on the Zcash chain and moving through the same shielded machinery, with swaps between them defined in a third proposal. The abstracts describe an extension of the Orchard protocol enabling the issuance, transfer and burn of custom assets. Every capability here is conditional, because none of it is implemented, and the specifications name no particular asset or issuer.
Why has ZSA taken so long?
The documents do not say, and this guide does not speculate. What the record shows is that ZIP 226 and ZIP 227 have carried Draft since May 2022, ZIP 228 has no creation date entered at all, and the swaps proposal depends on a transaction encoding described in a document the repository has since withdrawn. Consensus work is slow by design, so a long-lived draft is a weak signal on its own.
Does the Ironwood upgrade affect ZSA?
Possibly, and nothing published resolves it. All three proposals extend the Orchard protocol, and the July 2026 upgrade sealed the Orchard pool to new inflows. Against that, ZIP 2005, which governs the pool that replaced it, refers to recovering notes created under the ZSA extension if it were deployed. Two facts in tension, no published resolution, and any page that gives you one has gone past the documents.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are ZIPs 226, 227, 228 and 2005 and the Zcash Improvement Proposals index, the reference implementation's published API documentation, the proposing firm's own project page, and a community status thread updated August 20, 2026. All facts independently verified against cited documentation current as of August 2026. Nothing described here is deployed, and every capability sentence is written conditionally for that reason.