What determines a Zcash transaction fee? ZIP 317, explained

Zcash's official site tells newcomers that transaction fees are "usually only a few cents", but it does not explain how a fee is actually determined. The answer is ZIP 317, the Proportional Transfer Fee Mechanism, which obsoletes the earlier ZIP 313 convention of a flat 1,000 zatoshis (0.00001 ZEC) per transaction.

The motivation was fairness and abuse resistance. Under the flat fee, the network saw transactions with 1,100 outputs paying exactly what a 2-output payment paid. ZIP 317's stated objective is for fees to fairly reflect the processing costs that a transaction's inputs and outputs impose on network participants — discouraging intentional or unintentional denial-of-service usage patterns while keeping fees low for regular transactions.

Sources: Zcash: Privacy-protecting digital currency · ZIP 317: Proportional Transfer Fee Mechanism

ZIP 317 defines a conventional fee: the amount wallets conventionally pay and that a user can reasonably expect miners to accept for including a transaction in a block. The formula, in zatoshis, is marginal_fee × max(grace_actions, logical_actions), with marginal_fee set at 5,000 zatoshis and grace_actions at 2. Logical actions are a count derived from the transaction's inputs and outputs across all of its components, and the specification's requirements include that the fee scale linearly with the number of inputs and/or outputs.

Evaluating the formula at its floor gives the smallest conventional fee: max(2, logical_actions) is never below 2, so the minimum is 2 × 5,000 = 10,000 zatoshis — 0.0001 ZEC, using the specification's own equivalence of 1,000 zatoshis to 0.00001 ZEC. Transactions with more logical actions pay proportionally more. By requirement, the fee must be computable from only the public data of the transaction, so it does not leak private information used in constructing it.

Sources: ZIP 317: Proportional Transfer Fee Mechanism

Each component contributes to the count. Transparent inputs and outputs contribute the greater of two byte-size ceilings: total input size over the 150-byte standard P2PKH input size, and total output size over the 34-byte standard output size. Sapling contributes the greater of its spend and output counts, each legacy Sprout JoinSplit contributes 2, and Orchard contributes its number of Actions — an Orchard Action combines an input and an output in one structure.

Revision 1 of the specification, tied to the NU6.3 upgrade that introduces the Ironwood pool, adds an identical contribution for Ironwood Actions, which use the same Action structure as Orchard's. A stated design requirement is that the formula should not favour or discriminate against transactions involving any of the Ironwood, Orchard, Sapling, or transparent pools.

Sources: ZIP 317: Proportional Transfer Fee Mechanism

The two-action grace floor ensures there is no penalty for padding a one-action transaction up to two actions. Padding matters because the number of inputs and outputs is public: uniform transaction shapes reduce what that arity reveals. ZIP 317 notes that the default policy of zcashd and the mobile SDKs pads to two inputs and two outputs for each shielded pool a transaction uses, and it requires that users not be penalised for padding of this kind.

The same reasoning produced the logical-actions definition itself. An earlier proposal counted inputs plus outputs, which would have disadvantaged Orchard: because an Action combines an input and an output, Orchard requires padding inputs or outputs to equal numbers, so an inputs-plus-outputs fee would have effectively discriminated against it.

Sources: ZIP 317: Proportional Transfer Fee Mechanism

ZIP 317 is explicit on its own limits: "It is not a consensus requirement that fees follow this formula; however, wallets SHOULD create transactions that pay this fee, in order to reduce information leakage, unless overridden by the user." Paying the conventional amount keeps a transaction's fee from becoming a distinguishing mark, which is itself a privacy measure.

Revision status matters when reading the document. As of its June 26, 2026 update, ZIP 317 lists Revision 0 as Active, Revision 1 — the Ironwood contribution — as Draft for NU6.3, and Revision 2, which would add memo-bundle fee handling and depends on the not-yet-deployed ZIP 248, as Draft. Separately, ZECStats observes on-chain that the Ironwood pool activated on July 28, 2026 at block height 3,428,143. This page describes what the specification says; it does not establish which revision any particular wallet implements or what every transaction actually pays. For the live state of the pools the formula names, see the related ZECStats pages below.

Sources: ZIP 317: Proportional Transfer Fee Mechanism · ZECStats live summary

• network
• methodology
• ironwood
• shielded

All ZecStats insights