Ask what a Zcash transaction costs and result number 4 is a specification marked Obsolete, sitting on the project's own domain and quoting a figure that was superseded years ago. The document that replaced it does not rank for the question at all, so the wrong answer outranks the right one by default.
The replacement does not set a single number. It sets a formula, and the number that formula produces depends on what your transaction actually contains. A simple payment and a complicated one cost differently, on purpose.
Here is the formula, what feeds it, the floor that catches small payments, and the thing almost everyone gets backwards about shielded payments costing more than transparent ones.
The number you will find quoted is obsolete
Start here, because this is the reason the article exists rather than a detail inside it. A reader who looks up this question in good faith, clicks an authoritative-looking result, and writes down what it says will end up with a number that is wrong by an order of magnitude.
Position four for this query is zips.z.cash/zip-0313, titled "Reduce Conventional Transaction Fee to 1000 zatoshis". Its own header reads Status: Obsolete and Obsoleted-By: 317 (source: ZIP 313).
The document that superseded it carries the matching field in its own header, and the specification index lists 313 as Obsolete. Three independent places say the same thing, and none of it is a judgment call.
Why it matters is arithmetic. The current mechanism charges 5,000 zatoshis per unit of transaction work, with a floor of two units. So the cheapest possible transaction costs ten times the number sitting at position four, before anything complicated happens.
None of this is anyone's fault. Specifications do not get de-indexed when they are superseded, and a reader has no way to know that the fourth result is a historical document unless they open it and read the header.
The general lesson is cheap and worth keeping. On any project that publishes numbered specifications, the status line is the first thing to read and the last thing anyone quotes. A figure lifted from a document without checking whether that document is still the current one is a figure with no expiry date attached to it, which is worse than no figure at all.
How the fee is actually calculated
The formula is short enough to state in full, and seeing it first makes the explanation shorter. There are no hidden terms and no lookup tables. Two named parameters and a count of the work your transaction does are the whole of it, which is unusual for a fee mechanism.
The specification says wallets "SHOULD use a conventional fee, calculated in zatoshis, of conventional_fee = marginal_fee × max(grace_actions, logical_actions)" (source: ZIP 317).
Two parameters fill that in. The marginal fee is 5,000 zatoshis per logical action. Grace actions are 2.
So the whole thing reads: count the logical actions in your transaction, take whichever is larger of that count and two, and multiply by 5,000 zatoshis.
A logical action is the unit of work a transaction imposes, and the specification defines a contribution for each part of a transaction. Transparent inputs and outputs contribute by size, measured against standard reference sizes, with whichever side is larger deciding. Sapling contributes the larger of its spend count and its output count. Orchard contributes its action count directly. The pattern is that the busier side of a transaction sets the price, rather than both sides adding up.
The practical shape is that a transaction moving one thing to one place is cheap and stays cheap, and a transaction consolidating many small pieces is not.
Worth noticing what is absent from the formula. There is no block-space auction, no priority setting, and no relationship to how busy the network is at the moment you send. The same transaction costs the same at any hour.
Our guide to how transaction outputs work covers the accounting those counts come from, and why fees rise on other chains covers a very different fee model for comparison.
Why a shielded spend can cost more, without being a privacy surcharge
This is the part almost every explanation gets backwards, including the intuitive version most readers arrive with. It is worth slowing down for, because the wrong version is repeated confidently in a lot of places and it changes how people think about using the private side at all.
A shielded transaction often costs more than a transparent one. It is tempting to read that as a price on privacy, as though the protocol charges extra for the private option. The specification says the opposite in as many words.
ZIP 317's stated intention is "to make the fee paid for a transaction depend on its impact on the network, without discriminating between different transaction components (Ironwood, Orchard, Sapling, or transparent)".
Read that carefully. The mechanism is deliberately blind to which pool a transaction uses. There is no shielded rate and no transparent rate.
What varies is the action count. A shielded spend frequently carries more logical actions than a simple transparent payment does, and the fee follows the count rather than the category. Same rate, more units.
The practical consequence is that the fee difference is a fact about your particular transaction, not about privacy as a feature. Two shielded payments can cost very different amounts, and a complicated transparent transaction can cost more than a simple shielded one.
It is worth noting how little of this reaches the people building wallets in the form of guidance. The project's wallet UX checklist, which ranks third for this query on a high-authority domain, discusses fees in general terms and never mentions the specification that defines them or the unit it charges in (source: Zcash documentation).
Our guide to Zcash address types covers what the components are, if the pool names are unfamiliar.
The two-action floor, and the dust problem behind it
The floor is the part that surprises anyone making a small payment, and it exists for a reason that is worth understanding rather than resenting. It also produces a second effect that most people meet only when a wallet refuses to do something they expected it to do.
Because the formula takes the larger of the action count and two, a transaction with a single logical action pays as though it had two. The minimum is 10,000 zatoshis regardless of how trivial the payment is.
That looks like a penalty on small transactions and works as protection against a specific problem. Fees that scale purely with work make it cheap to flood a network with minimal transactions, and a floor removes that.
There is a second-order effect the reference implementation calls out directly. Its fee module notes that change selection under these rules "requires careful handling of low-valued inputs to ensure that inputs added to a transaction do not cause fees to rise by an amount greater than their" own value (source: zcash_client_backend).
In plain terms: adding a tiny input to a transaction adds an action, and an action costs 5,000 zatoshis. If the input is worth less than that, spending it loses money. Wallets have to notice this and decline, which is why a balance can be technically spendable and practically stuck.
The rules are implemented rather than merely written, and the library carrying them is versioned and updated alongside the rest of the wallet stack (source: librustzcash changelog), which is the difference between a fee policy and a fee proposal.
Our guide to choosing fees on Bitcoin covers a chain where the user makes this trade manually instead, and reading a block explorer shows what a fee actually looked like after the fact.
Which revision applies, and why the documents do not settle it
Here the honest answer is that the public record is in tension with itself, and saying so plainly is better than picking whichever side reads more confidently. Three facts are each verifiable, and together they do not resolve into a single statement about what is running right now.
The specification's status line reads "[Revision 0] Active, [Revision 1: NU6.3] Draft, [Revision 2] Draft", and it was last updated on June 26, 2026. The index lists the same three statuses (source: Zcash Improvement Proposals).
Inside the same document, Revision 0 is described as the mechanism "in effect prior to NU6.3", and Revision 1 "adds a contribution for Ironwood-pool Actions, to be enacted at NU6.3". Revision 2 is explicitly a draft that "depends on ZIP 248, which has not yet been deployed".
Now put that beside the upgrade record. The project's own page states that NU6.3 activated on July 28, 2026, which is a month after the specification was last updated.
So the body says Revision 1 takes effect at an upgrade that has since happened, and the status line still calls Revision 1 a Draft. Both readings are on the record and this article asserts neither, because a document status describes a document rather than a running network.
What is safe to say is the shape: the formula, the 5,000 zatoshi marginal rate and the two-action floor are Revision 0 material and are the Active mechanism as documented. A pool-specific contribution was written for the most recent upgrade. Anyone needing the exact figure a wallet will charge today should read it from a wallet rather than from any page.
What the fee mechanism leaves out
Four things this mechanism leaves alone, and the first of them is what separates this chain from most others a reader will have used. Each is a question the fee formula genuinely does not answer, and each has its answer somewhere else.
There is no bidding. Fees here are conventional rather than competitive: the specification tells wallets what they should charge, and users are not outbidding each other for block space. Our guide to the Bitcoin mempool covers the auction model this replaces.
It does not fix a price in money. Everything above is in zatoshis, which is a fixed fraction of a ZEC and not a fixed amount of anything else. What a transaction costs in any currency moves with a market what follows takes no view on.
It does not describe miner economics. What fees mean for the people assembling blocks, and how they sit against the block subsidy, belongs to our guide to How Zcash mining works.
And it is not the last word. A separate proposal would add "an explicit fee field to the v6 transaction format", so that "instead of fees being implicit in the difference between the input value and output value of the transaction, all value transfers, including fee transfers to miners, will be explicit and committed to via the txid". Its stated motivation opens on the principle that fee selection "should be very hard to make mistakes" in (source: ZIP 2002).
That proposal carries the status Draft, and its discussion is open in the specification repository (source: zcash/zips issue 803). So the mechanism described here is current rather than permanent, and the direction of travel is toward making the fee something a transaction states outright rather than something you infer by subtraction.
If wallet mechanics generally are the unfamiliar part here, how crypto wallets work is the place to start.
BloFin does not set or collect network fees, which is why what follows is about the specification rather than a schedule.
What the fee rule means in ordinary use
Four practical consequences follow from a fee set by transaction shape rather than by an auction, and they are the reason this chain feels different to use.
Fees are predictable in advance. Because the figure depends on the number of inputs and outputs rather than on how busy the network is, a wallet can state the cost before you commit and be right. There is no equivalent of watching a fee market and choosing a moment.
Congestion does not price you out. On a chain where fees are auctioned, a period of heavy demand makes small payments uneconomic. Here the rule does not respond to demand at all, which trades one property for another: predictable cost, and no market mechanism to prioritize during genuine congestion.
Consolidating many small notes costs more than moving one large one. The rule scales with the number of items the transaction touches, so a balance accumulated in small pieces is more expensive to move than the same balance received once. Wallets sometimes offer to consolidate during quiet periods for exactly this reason.
And a shielded spend is not surcharged for being private. Where a shielded transaction costs more, it is because it involves more items rather than because privacy carries a premium, and the distinction matters because the first is avoidable and the second would not be.
Why the documents disagree, and what to do about it
The specification governing this has more than one revision, and material quoting it does not always say which.
A revision describes a proposed change to the rule and carries its own status. A revision that has not activated describes what the rule would be rather than what it is, which is the same documentary-versus-deployed gap that appears throughout this subject.
The practical consequence for a reader is narrow. Any specific figure quoted for a Zcash fee should carry a date and a revision, and one that carries neither is describing an unspecified moment. The mechanism, which is what this page is about, is more stable than any number derived from it.
The check that settles it is the same one that settles every question of this kind. Look at what the network is charging now rather than at what a document says it should charge, and treat the document as an explanation of the number rather than as its source.
Why a predictable fee is unusual, and what it costs
Fee predictability is rare enough on public chains that it is worth naming what is being traded for it.
An auction allocates scarce block space to whoever values it most, which is efficient in the economic sense and unpleasant in practice. It means the cost of a payment depends on what everyone else is doing, that small payments become uneconomic under load, and that a wallet cannot tell you the price in advance with any confidence.
A rule based on transaction shape gives up that allocation mechanism entirely. The cost is knowable before you send, it does not move with demand, and small payments stay viable. What is given up is the ability to pay for priority, which means that under genuine congestion there is no mechanism to sort urgent payments from patient ones.
Which of the two is better depends on what the chain is for, and it is a real design disagreement rather than an oversight. What is worth carrying away is that the predictability people notice here is not an accident of low usage. It is the direct output of a rule that does not respond to demand, and it would behave the same way at any level of activity.
Frequently asked questions
How much does a Zcash transaction cost?
There is no single number, which is why the obsolete document quoting one still ranks. The current mechanism multiplies a marginal fee of 5,000 zatoshis by whichever is larger of your transaction's logical action count and two. So the cheapest possible transaction is 10,000 zatoshis, and anything with more moving parts costs proportionally more. A wallet computes this for you from the transaction it is about to build.
Do shielded transactions cost more than transparent ones?
Often, and not because they are shielded. The specification states that the intention is to make the fee depend on a transaction's impact on the network without discriminating between transaction components, so there is no separate shielded rate. A shielded spend usually carries more logical actions, and the fee follows the action count. A complicated transparent transaction can cost more than a simple shielded one.
Why is there a minimum fee even for a tiny payment?
Because the formula takes the larger of your action count and a grace figure of two, a one-action transaction pays for two. That floor makes it expensive to flood the network with minimal transactions. It also has a side effect worth knowing: since each additional input adds an action costing 5,000 zatoshis, an input worth less than that costs more to spend than it is worth, and a well-built wallet will decline to include it.
Which version of the fee rules is currently live?
The documents do not settle that cleanly and this guide does not pretend otherwise. The specification's status line lists Revision 0 as Active and Revision 1 as Draft, while its body describes Revision 1 as enacted at the NU6.3 upgrade, which the project records as having activated on July 28, 2026. The specification was last updated a month before that. Read the fee your wallet quotes rather than relying on any page for the current figure.
Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Primary sources include the Zcash Improvement Proposals repository, its specification index, and the reference wallet library's published documentation. All facts independently verified against cited documentation current as of August 2026. Every fee here is stated in zatoshis and never converted to any currency, and no claim is made about which specification revision the network computes today.
This article is for educational purposes only and is not financial advice. Cryptocurrency is volatile and you can lose money. Do your own research before making any decision.