Send a transparent payment and your wallet assembles a few hundred bytes and signs them. Send a shielded one and it must first execute a substantial cryptographic computation, consuming memory and processor time in quantities a transparent construction never approaches. That differential constitutes the privacy mechanism itself, relocated onto hardware you own, and 5 consequences follow.
The relocation is sufficiently unusual to warrant examination on its own terms. Costs in a distributed system are conventionally borne by the network and distributed across its participants; this one is borne exclusively by the sender, before the transaction has any existence at all, and everything the remainder of what follows describes is downstream of that architectural decision.
Where the work actually happens
A shielded transaction cannot be assembled by a remote server on your behalf without surrendering to that server precisely the information the transaction exists to conceal. Construction must consequently execute wherever the secrets already reside, which under any coherent threat model means the sending wallet rather than infrastructure operated by somebody else.
This constraint is observable in how the software is packaged rather than merely asserted in documentation. The reference implementation distributes proving as a library, published as a crate whose stated purpose is "Zcash zk-SNARK circuits and proving APIs" (source: zcash_proofs).
A library, not a service. Anything calling it, whether a desktop client or a phone application, executes the proving work in its own process on its own hardware.
The consequence is an asymmetry that runs through everything below. Producing the proof is expensive and happens once, on one device belonging to one person. Checking it is cheap and happens thousands of times, on every node that ever validates the block. The system deliberately concentrates cost at the point where exactly one participant bears it.
That trade is why the design remains viable at network scale, and simultaneously why your phone becomes noticeably warm during a shielded send.
The distribution is worth quantifying qualitatively even without benchmarks. A proof constructed once may subsequently be verified by every node that validates its block, by every node that later synchronizes the chain from genesis, and by every node that has not yet been built. Concentrating expense at the single point of construction is therefore not merely convenient; it is the only arrangement under which the aggregate cost of privacy remains bounded as the network's lifetime extends.
What the wallet is computing, and why verification is cheap
The unit of work corresponds to the circuit rather than to the transaction as a user conceives of it, and the number of times that circuit must be satisfied is determined by the transaction's internal structure rather than by its apparent simplicity on screen.
The current shielded protocol batches that work. Its specification groups a transaction's value movements into one collection and requires exactly one proof to cover the whole collection (source: ZIP 224), so proving cost tracks that grouping rather than scaling separately with every movement inside it.
Compare that to how a transparent chain handles the same growth. On a transparent output model, adding an input adds a signature and some bytes, and the marginal cost is trivial. Here the marginal cost is a constraint added to a circuit that then has to be proved.
Verification sits at the opposite extreme and is worth stating precisely, because it is the reason none of this burdens the network. Proofs of this construction are engineered to be small objects that a verifier can check quickly (source: Wikipedia), and the project's own material puts the checking side at milliseconds.
So the cost the network pays is negligible and the cost you pay is not. Our guide to Zk snarks covers why the construction was engineered with that asymmetry rather than the reverse.
The practical implication for anybody estimating cost is that transaction complexity, measured in value movements, is the variable to watch. A shielded send consolidating many small holdings imposes materially more proving work than one spending a single large holding of identical total value, and no interface currently surfaces that distinction before the operation begins.
The 2018 collapse in cost, and what it unlocked
Throughout the first two years of the protocol's operational life, this expenditure constituted an absolute barrier rather than a mere inconvenience, excluding entire categories of consumer hardware from participating in the shielded side under any circumstances whatsoever, irrespective of the operator's patience.
The network upgrade deployed in 2018 changed the figures by an order of magnitude. The project's own page for that upgrade states that shielded payments "can be constructed in as little as a few seconds and with only 40 megabytes of memory" (source: Zcash).
Forty megabytes is the number that matters. A memory requirement measured in gigabytes excludes phones categorically, regardless of patience, because the allocation simply fails. A requirement measured in tens of megabytes does not. The same page frames the intent in exactly those terms, describing efficiency improvements meant to "pave the way for broad mobile, exchange and vendor adoption" of shielded addresses.
The same upgrade introduced a second property with consequences most summaries omit. The same upgrade page describes it as allowing the hardware that constructs the zero-knowledge proof to operate independently of the hardware that signs for the transaction.
Separating those two jobs is what makes constrained signing devices workable at all. A device holding spending authority no longer needs the memory or the processor to build a proof, because a more capable machine can construct it while the constrained one signs. That separation is the mechanism underneath hardware wallet support and behind the same reasoning as air-gapped signing. Our guide to Zcash hardware wallet support covers the current state of that support, which is a different question from whether the protocol permits it.
Which upgrade this was, and how upgrades get scheduled, belongs to our guide to Zcash network upgrades.
Parallelism, and what it means on a slow device
Proving has become compute-bound rather than memory-bound, which substantially changes what determines the duration of the wait. The dominant variable ceased being whether a device can allocate sufficient memory and became instead how many processor cores it can bring to bear concurrently on the underlying computation.
The implementation is explicit about the dependency. It "uses rayon for parallel computation", the thread count is configurable through an environment variable, and the repository carries a direct warning: disabling the multicore feature means the library "will lose access to parallelism", which "will significantly degrade performance" (source: zcash/halo2).
Three practical consequences follow from that dependency, and a wallet's interface surfaces none of them.
Core count matters more than clock speed. A modern phone with several performance cores can outperform an older machine with a faster single core, which inverts the usual intuition about which device is quicker.
Build configuration is a real variable. Two wallets running identical protocol logic can differ substantially in proving time because one of them was compiled without parallel support, and nothing in either interface would tell you. Our comparison of wallet security models covers the broader point that wallets differ in ways their interfaces never disclose.
And thermal throttling is a genuine factor on sustained work. A device that has been busy will prove more slowly than the same device at rest, which is why timings quoted in benchmarks rarely match what a user observes.
Our guide to Zcash halo2 handles the identity of the current proving system and what its adoption changed.
What proving cost leaves unexplained
Proof generation constitutes one expenditure among several, and it is routinely credited with delays and charges to which it bears no causal relationship whatsoever. Four separations are consequently worth articulating explicitly, since each is misattributed frequently enough to have become conventional wisdom.
It is not the network fee. Proving cost is paid in your own electricity and patience, to nobody. The fee is a separate quantity paid to the network in ZEC, determined by rules that have nothing to do with how hard your device worked. Our guide to Zcash transaction fees covers how those rules operate.
It does not explain why a shielded balance takes time to appear. That delay is scanning, meaning the wallet trial-decrypting outputs to discover which ones belong to it, and it is a fundamentally different operation from proving. Confusing the two produces a wrong model of why light wallets behave as they do, which our explainer on full nodes against light clients sets up in the general case.
It is not fixed forever. Proving cost is a property of a circuit, and circuits are replaceable. The system now in use was adopted partly because it enables "future circuit upgrades" without repeating a procedure the earlier ones required (source: Electric Coin Company), so today's figures describe today's circuit rather than a permanent floor.
And it says nothing about privacy. A proof that took ten seconds conceals exactly what a proof that took one second conceals. Speed is an engineering property; what is hidden is a protocol property, and the two are independent. Our guide to Zcash shielded pools covers which pool a given balance occupies, which is the question that actually determines visibility, and our security checklist covers the operational habits that determine considerably more of the outcome than any protocol property does.
The verification side, meanwhile, stays cheap regardless. Proofs of this kind are designed to be checked "within a few milliseconds" (source: Zcash), which is why no amount of proving expense on your side ever becomes a burden on anyone else's.
Where the cost shows up in ordinary use
Proving cost is invisible until it is not, and it surfaces in four situations that look unrelated until the common cause is named.
Sending from a phone is the first and most common. A device that handles everything else comfortably can take noticeably longer here than a desktop, and the difference is entirely the arithmetic rather than the network. Users routinely interpret the pause as a connectivity problem and retry, which produces a second proof rather than a faster one.
Consolidating many small notes is the second. A wallet spending several inputs proves a statement about each, so the work scales with the number of notes rather than with the amount. This is why a balance built up from many small receipts costs more to move than the same balance received once, and why wallets sometimes offer to consolidate during quiet periods.
Restoring a wallet is the third, and it is a different cost with a similar symptom. Restoration is dominated by scanning rather than by proving, since the wallet has to trial-decrypt candidate outputs to find its own. Both feel like waiting and they have different causes and different fixes, which is worth knowing before troubleshooting either.
Running on constrained hardware is the fourth. Devices with limited working memory pay a disproportionate penalty, because the construction wants its working set resident and a device forced to move it to slower storage loses far more time than the shortfall suggests.
None of the four is avoidable by choosing different software, because all of them are properties of the construction rather than of any implementation. What differs between wallets is how honestly the wait is presented, and that is a genuine differentiator worth weighing.
The cost also sets a design constraint that shows up throughout the ecosystem. Any feature requiring a proof inherits the proving cost, which is why interfaces built around this chain tend to batch operations, warn before expensive ones, and offer delegation as an escape hatch. Reading those design choices as arbitrary misses that all three are responses to the same underlying arithmetic, and that arithmetic is the price of not publishing the amounts.
One further consequence belongs with that. Because proving cost falls as implementations improve while verification cost stays roughly flat, the practical experience of using the private side has improved substantially over the protocol's life without the chain's own workload changing. Anyone whose impression of the cost dates from an earlier generation of the software is carrying a figure that no longer describes the current position by a wide margin.
What determines how long a transaction takes on your device
Four factors dominate, and their relative weight explains why the same wallet feels instant on one machine and sluggish on another.
Processor capability dominates everything else. Proof construction is arithmetic-bound rather than input-output-bound, so the figure that predicts the wait is how much computation the device can perform per unit of time rather than how much storage or bandwidth it has. A recent desktop processor and a mid-range phone from several years ago differ by more than an order of magnitude on exactly this workload.
Available memory sets a floor below which nothing is fast. The construction requires working space during proving, and a device forced to swap that working set to slower storage pays a penalty out of all proportion to the shortfall. This is the usual explanation for a device that handles most software comfortably and then stalls specifically here.
The number of inputs and outputs scales the work. A transaction consuming several notes and producing several requires proving statements about each, so a wallet consolidating many small notes does materially more work than one spending a single large one. This is the reason a balance accumulated in many small receipts can be slower to spend than the same balance received once.
Whether the wallet proves locally or delegates the work is the fourth, and it is a design decision rather than a hardware property. Delegating removes the wait and introduces a party that learns something about the transaction, which is a trade that belongs in the open rather than in a settings menu.
Why verification cost is the asymmetry that makes any of this workable
The expense of constructing a proof is only half the picture, and the other half is what makes the design viable at network scale.
Constructing a proof is expensive and is performed once, by the party with an interest in the transaction being accepted. Verifying it is cheap and is performed by every validating node on the network, independently, forever.
That asymmetry is the entire economic argument for the architecture. If verification scaled with construction, every node would repeat the sender's work for every shielded transaction ever made, and the chain would be unusable within a short period. Because it does not, the cost of privacy is borne by the party choosing it rather than levied on everyone else in perpetuity.
Two consequences follow that are easy to miss. Historical validation stays cheap, so a node syncing from the beginning is not doing proportionally more work as the shielded history grows. And improvements to proving speed benefit senders directly without requiring any change to what verifiers do, which is why proving cost has fallen substantially over the protocol's life while verification has remained roughly where it was.
Frequently asked questions
Why does a shielded Zcash transaction take longer to send?
Because the sending device has to construct a zero-knowledge proof before the transaction exists, and that computation cannot be delegated to a server without disclosing what the transaction conceals. A transparent send assembles bytes and signs them. A shielded send runs a circuit first. The delay you observe is that computation, executing locally on your own hardware. How long it takes depends on the device's core count and on how many value movements the transaction contains.
How much memory does a shielded Zcash transaction need?
The project's page for the 2018 network upgrade states that shielded payments can be constructed in as little as a few seconds and with only 40 megabytes of memory. Before that upgrade the requirement was large enough to exclude phones categorically. Current figures depend on the circuit in use and on the device, so treat any specific benchmark as describing one moment rather than a permanent property.
Does proof generation cost me a higher network fee?
No. These are separate quantities paid to different parties. Proof generation costs your device processor time and memory, and is paid to nobody. The network fee is paid in ZEC according to rules that do not reference how hard your device worked. A slow proof and a low fee can coexist, and frequently do. Our guide to Zcash transaction fees covers the rules that set the fee, none of which reference proving at all.
Can a hardware wallet build a Zcash shielded proof?
It generally does not need to. The 2018 upgrade decoupled the hardware that constructs the proof from the hardware that signs, so a constrained device can hold spending authority while a more capable machine performs the proving work. Whether a specific device supports Zcash shielded operations is a separate question about that product rather than about the protocol, and our guide to Zcash hardware wallet support covers the current state of it.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources are the zcash_proofs crate documentation, ZIP 224, the project's own upgrade page for the 2018 network upgrade, the Halo 2 implementation repository, an Electric Coin Company technical explainer, and two reference pages. All facts independently verified against cited documentation current as of August 2026. what follows covers device cost; network fees, wallet selection, upgrade history and the identity of the proving system belong to the articles that own them.