VI Wallet Guide: The Zcash wallet layer: keys, transactions, and light-client synchronisation 9 Anchors, confirmations, and expiry 11 Transaction construction

10 Fees (ZIP 317)

This section states the fee a wallet pays. It fixes the fee as a consensus quantity, defines the conventional fee of ZIP 317 over logical actions and bounds it before signing; it states the padded Action counts on which the fee is computed; and it states the relay, mempool and block-template rules that apply to a transaction paying less.

10.1 The conventional fee

For a transaction other than a coinbase transaction, the transaction fee is the value remaining in its transparent transaction value pool: the sum of its transparent input values and of the balancing values of its shielded pools, minus the sum of its transparent output values (protocol specification, §“Transactions and Treestates”; Ironwood Guide, Definition “Transparent transaction value pool” and Definition “Balancing value”, in “The balancing value”). Consensus requires it to be non-negative. No transaction field encodes it, and every term of the sum is public, so the fee is public.

A fee rule for a shielded protocol meets the requirements of ZIP 317, “Requirements”: the fee is computable from the public data of the transaction alone, since a fee that depended on private construction data, such as which notes were spent or what change was returned, would disclose that data; it scales linearly with the numbers of inputs and outputs, which makes transaction-rate denial of service costly (ZIP 317, “Motivation” and “Denial of Service”); it neither penalises padding for privacy nor favours any pool; and it lets a small number of inputs of value below the marginal fee be spent. A fee other than the one every wallet pays distinguishes the wallet that chose it: non-standard fees may reveal specific users, wallets or wallet versions (ZIP 317, “Security and Privacy considerations”).

The conventional fee (Definition 10.2) is not a consensus rule. ZIP 317, “Fee calculation”, states that it is not a consensus requirement that fees follow the formula, and that wallets SHOULD create transactions that pay it, to reduce information leakage, unless overridden by the user. It binds through relay and block-template policy only (§10.3). ZIP 259, “NU7 consensus changes”, changes neither the formula nor its parameters.

In what follows, $\lceil x\rceil$ is the least integer $\geq x$ and $\lfloor x\rfloor$ the greatest integer $\leq x$ , for real $x$ .

Definition 10.1 (Logical actions).

Let a transaction of version $5$ or version $6$ have the following public fields of its final encoding (protocol specification, §“Transaction Encoding and Consensus”; ZIP 229, “Transaction Format”), each a non-negative integer:

•

$\mathit{tx\_in\_total\_size}$ and $\mathit{tx\_out\_total\_size}$ , the byte lengths of the encoded fields $\mathtt{tx\_in}$ and $\mathtt{tx\_out}$ , the concatenations of the encoded transparent inputs and outputs;
•

$\mathit{nJoinSplit}$ , the number of Sprout JoinSplit descriptions;
•

$\mathit{nSpendsSapling}$ and $\mathit{nOutputsSapling}$ , the numbers of Sapling spend and output descriptions;
•

$\mathit{nActionsOrchard}$ , the number of Orchard-pool Actions;
•

$\mathit{nActionsIronwood}$ , the number of Ironwood-pool Actions, $0$ in a version $5$ transaction.

With the parameters $\mathit{p2pkh\_standard\_input\_size}:=150$ and $\mathit{p2pkh\_standard\_output\_size}:=34$ , in bytes, the number of logical actions of the transaction is

	$\displaystyle\mathit{logical\_actions}:=\;$	$\displaystyle\max\bigl{(}\lceil\mathit{tx\_in\_total\_size}/150\rceil,\,\lceil% \mathit{tx\_out\_total\_size}/34\rceil\bigr{)}$
		$\displaystyle+2\,\mathit{nJoinSplit}+\max(\mathit{nSpendsSapling},\,\mathit{% nOutputsSapling})$
		$\displaystyle+\mathit{nActionsOrchard}+\mathit{nActionsIronwood},$

the sum of the transparent, Sprout, Sapling, Orchard and Ironwood contributions, in that order (ZIP 317, “Fee calculation”, the contributions of Revision $0$ and Revision $1$ ).

The Sprout contribution $2\,\mathit{nJoinSplit}$ is $0$ in every valid transaction: transactions of version $5$ and version $6$ have no JoinSplit field, and transactions of version $4$ are invalid under NU7 (ZIP 2003; ZIP 259, “NU7 consensus changes”). The term is kept so that the definition is that of ZIP 317. The two divisors are the maximal encoded sizes of a P2PKH input and output (ZIP 317, “Rationale for the chosen parameters”):

	$\displaystyle 150$	$\displaystyle=36\ (\text{outpoint: }32\text{-byte txid},\ 4\text{-byte index})% +110\ (\text{script})+4\ (\text{sequence}),$
	$\displaystyle 110$	$\displaystyle=1\ (\text{length})+1\ (\text{signature length})+72\ (\text{% signature})+1\ (\text{sighash type})$
		$\displaystyle\quad+1\ (\text{key length})+33\ (\text{compressed key})+1\ (% \text{margin}),$
	$\displaystyle 34$	$\displaystyle=8\ (\text{value})+1\ (\text{script length})+25\ (\text{P2PKH % script}).$

Charging transparent parts by size rather than by count charges a large script in proportion to its size; a 2-of-3 P2SH multisig input, about 70% larger than a P2PKH input, is counted so (same section).

Definition 10.2 (Conventional fee).

Let $\mathit{marginal\_fee}:=5000$ zatoshi per logical action and $\mathit{grace\_actions}:=2$ . The conventional fee of a transaction with $\mathit{logical\_actions}$ as in Definition 10.1 is

\mathit{conventional\_fee}:=\mathit{marginal\_fee}\cdot\max(\mathit{grace\_% actions},\,\mathit{logical\_actions})\text{ zatoshi}

(ZIP 317, “Fee calculation”).

The parameter values and their rationale are ZIP 317’s (“Rationale for the chosen parameters”).

Remark 10.3 (Revisions of the fee rule).

ZIP 317, “Fee calculation”, defines $\mathit{logical\_actions}$ as the sum of the contributions of the applicable revision, and a contribution defined by a revision is included in every later one (ZIP 317, “Revisions”). Revision $0$ defines the transparent, Sprout, Sapling and Orchard contributions. Revision $1$ adds the Ironwood contribution $\mathit{nActionsIronwood}$ : Ironwood-pool Actions have the Action structure of Orchard-pool Actions and are counted identically. Revision $2$ adds a contribution for memo bundles (ZIP 231), defined on the transaction format of ZIP 248, which NU7 does not introduce (ZIP 259, “Rationale for no new transaction format”). Definition 10.1 is therefore Revision $0$ with the Revision $1$ term. The statuses of these ZIPs are those of Table 1.

Corollary 10.4 (The minimum fee).

Every transaction with $\mathit{logical\_actions}\leq 2$ has conventional fee $\mathit{marginal\_fee}\cdot\mathit{grace\_actions}=5000\cdot 2=10{,}000$ zatoshi, and no transaction has a smaller conventional fee.

Proof.

By Definition 10.2, since $\max(2,\mathit{logical\_actions})=2$ when $\mathit{logical\_actions}\leq 2$ , and $\max(2,\mathit{logical\_actions})\geq 2$ always. □

A wallet computes the fee before it signs, and the encoded size of a transparent input depends on its signature. The following proposition bounds the fee from the unsigned transaction.

Proposition 10.5 (Fee estimate before signing).

Let a wallet fix, before signing, every field of a transaction except the scripts of its transparent inputs $1,\dots,k$ , and assign to each input $i$ a bound $b_{i}\in\mathbb{N}$ on its encoded size after signing, as follows:

(i)

$b_{i}=150$ for a P2PKH input spending a public key with a compressed $33$ -byte encoding, such as each of the wallet’s own transparent keys;
(ii)

otherwise any $b_{i}$ known to bound the encoded size of the signed input.

Let $\mathit{fee}_{\mathsf{est}}$ be the conventional fee computed with $\mathit{tx\_in\_total\_size}$ replaced by $\sum_{i=1}^{k}b_{i}$ . Then $\mathit{fee}_{\mathsf{est}}$ is at least the conventional fee of the signed transaction.

Proof.

Signatures enter only the scripts of the transparent inputs, so the field $\mathtt{tx\_out}$ and every shielded count of Definition 10.1 are the same in the unsigned and the signed transaction. A DER-encoded signature has at most $72$ bytes, so the script of a P2PKH input with a compressed key has at most $1+1+72+1+1+33=109$ bytes and the input at most $36+109+4=149\leq 150$ bytes; under clause (ii) the bound holds by hypothesis. The signed $\mathit{tx\_in\_total\_size}$ is therefore at most $\sum_{i}b_{i}$ . The maps $x\mapsto\lceil x/150\rceil$ , $(a,b)\mapsto\max(a,b)$ , the addition of the unchanged remaining contributions, and $n\mapsto 5000\cdot\max(2,n)$ are each non-decreasing in every argument, so their composition is, and $\mathit{fee}_{\mathsf{est}}$ is at least the conventional fee of the signed transaction. □

Hypothesis (i) does not extend to a P2PKH input with an uncompressed $65$ -byte key encoding, which has up to $181$ bytes and needs $b_{i}\geq 181$ under (ii). For an input with no known bound on its signed size, the fee is unknown before signing.

10.2 The fee on padded counts

The fields of Definition 10.1 are those of the final encoded transaction: every bundle padded and every change output included (ZIP 317, “Fee calculation”). A wallet therefore prices a transaction by predicting its padded shape (Definition 10.6) and its change before it selects inputs; a fee computed on unpadded counts underpays whenever padding adds a logical action. This rule is ZIP 317’s and is not a consensus rule.

Definition 10.6 (Padded Action count).

Let a bundle of the Orchard protocol, in the Orchard pool or the Ironwood pool, have $s\in\mathbb{N}$ real spends and $o\in\mathbb{N}$ real outputs, and let $\mathsf{enableCrossAddress}\in\{0,1\}$ be its flag value (Ironwood Guide, §“Bundle flags”, Definition “Flag values and expanded receiver”). Its requested Action count is

r(s,o):=\begin{cases}\max(s,o)&\text{if }\mathsf{enableCrossAddress}=1,\\ s+o&\text{if }\mathsf{enableCrossAddress}=0,\end{cases}

and its padded Action count is $n(s,o):=0$ if $s=o=0$ and $n(s,o):=\max(r(s,o),2)$ otherwise. The counts $\mathit{nActionsOrchard}$ and $\mathit{nActionsIronwood}$ of Definition 10.1 are the padded Action counts of the two bundles. A non-empty Sapling bundle with $s$ real spends and $o$ real outputs has $\mathit{nSpendsSapling}=s$ and $\mathit{nOutputsSapling}=\max(o,2)$ .

The count $s+o$ is that of the pairing a wallet performs when cross-address transfers are disabled: the note an Action creates has the expanded receiver of the note it consumes, so each real spend occupies an Action with a fabricated zero-valued output at its own receiver, and each real output an Action with a fabricated zero-valued spend at its receiver (ZIP 326, “Fabricated same-address outputs and randomized note ciphertexts”; ZIP 374, “Fabricated same-address outputs (NU6.3)”), respectively. Every Orchard-pool bundle has $\mathsf{enableCrossAddress}=0$ (Ironwood Guide, “Chain state and pool rules”, rule (i); ZIP 258, “Consensus rules from NU6.3 activation”); an Ironwood-pool bundle may set it to $1$ .

The floor $2$ and the Sapling padding are a padding policy, designed but unspecified in the sense of Definition 1.1. Their only general ZIP anchor is non-normative: ZIP 317, “Requirements”, notes that standard builders pad to two inputs and two outputs for each shielded pool, and “Rationale for the chosen parameters” calls padding to two actions the standard approach; ZIP 318 fixes the padding of its migration and note-preparation transactions only (below). The Sapling rule departs from ZIP 317’s remark by adding no spend beyond those needed. Dummy Sapling spends, which this policy does not use, are constructed as in protocol specification, §“Dummy Notes (Sapling)”; the dummy Actions of the Orchard protocol are those of §11.7. Logical actions count an Action once: a charge per input plus per output would penalise the padding that the Action structure forces, since each Action consumes one note and creates one, and the maximum in each contribution favours no pool (ZIP 317, “Rationale for logical actions”).

ZIP 318 specifies two exceptions. Under “Canonical migration transaction structure”, a canonical migration transaction has one Orchard-pool spend in an Orchard-pool bundle of exactly two Actions, one spend Action and one output Action that carries either change or a zero-valued dummy output (ZIP 318, “Rationale for the canonical transaction shape”), and one Ironwood-pool output in an unpadded Ironwood-pool bundle of one Action. Its $\mathit{logical\_actions}$ is $3$ and its conventional fee $15{,}000$ zatoshi. The “canonical fee (provisionally the ZIP 317 minimum fee)” of ZIP 318 is read here as this conventional fee: read as $10{,}000$ zatoshi, it leaves one unpaid action (Definition 10.8). A note-preparation transaction SHOULD have an Orchard-pool bundle of exactly $16$ Actions, padded as needed (ZIP 318, “Note preparation transactions”), so its count is $16$ , not $n(s,o)$ .

Proposition 10.7 (Fee of a single-pool payment).

Consider a transaction with no transparent inputs or outputs, one input note and one payment output, with or without one change output, whose bundles are padded as in Definition 10.6.

(a)

If the input note and every output lie in the Ironwood pool, in a bundle with $\mathsf{enableCrossAddress}=1$ , or all lie in the Sapling pool, the conventional fee is $10{,}000$ zatoshi.
(b)

If the input is a single Orchard-pool note, the payment output lies in the Ironwood pool, and the change output, if any, lies in the Orchard pool or the Ironwood pool, then the conventional fee is $20{,}000$ zatoshi.

Proof.

(a) In the Ironwood pool $s=1$ and $o\in\{1,2\}$ , so $r=\max(1,o)\leq 2$ and $n=2$ . In the Sapling pool the contribution is $\max(1,\max(o,2))=2$ . In either case $\mathit{logical\_actions}=2$ , and Corollary 10.4 gives $10{,}000$ zatoshi.

(b) No value enters the Orchard pool, since $\mathsf{valueBalanceOrchard}\geq 0$ for every transaction (Ironwood Guide, “Chain state and pool rules”, rule (ii); ZIP 258, “Consensus rules from NU6.3 activation”), and an Orchard-pool output lies at the receiver of the note consumed in its Action; so a payment to another party cannot lie in the Orchard pool, and the full routing rule is that of §11.2. The payment lies in the Ironwood pool by hypothesis. The Orchard-pool bundle has $s=1$ and $o\in\{0,1\}$ , so $r=s+o\leq 2$ and $n=2$ . The Ironwood-pool bundle has $s=0$ and $o\in\{1,2\}$ , so $n=2$ . Hence $\mathit{logical\_actions}=4$ and the conventional fee is $5000\cdot 4=20{,}000$ zatoshi. □

10.3 Relay, mempool, and block template

The conventional fee binds through three mechanisms, none of them a consensus rule. Nodes that normally relay transactions are expected to relay those paying at least the conventional fee, unless other reasons of robustness or denial-of-service mitigation apply (ZIP 317, “Transaction relaying”). Mempool size limiting adds a penalty $\mathit{low\_fee\_penalty}$ to the eviction weight of a transaction paying less than the conventional fee (ZIP 401; ZIP 317, “Mempool size limiting”). Block-template construction limits the unpaid actions of a block (Definition 10.8).

Definition 10.8 (Unpaid actions).

For a transaction $\mathit{tx}$ with fee $\mathit{tx.fee}$ as in §10.1 and $\mathit{tx.logical\_actions}$ as in Definition 10.1, the number of unpaid actions is $\mathit{unpaid\_actions}(\mathit{tx}):=0$ if $\mathit{tx}$ is a coinbase transaction, and otherwise

\mathit{unpaid\_actions}(\mathit{tx}):=\max\bigl{(}0,\,\max(\mathit{grace\_% actions},\,\mathit{tx.logical\_actions})-\lfloor\mathit{tx.fee}/\mathit{% marginal\_fee}\rfloor\bigr{)}.

The unpaid actions of a block are the sum over its transactions. The recommended block-template algorithm adds a transaction that pays less than the conventional fee only while that sum stays at most $\mathit{block\_unpaid\_action\_limit}=50$ (ZIP 317, “Recommended algorithm for block template construction”).

Lemma 10.9 (Zero unpaid actions).

A transaction other than a coinbase transaction has $\mathit{unpaid\_actions}=0$ if and only if its fee is at least its conventional fee.

Proof.

Let $m:=\max(\mathit{grace\_actions},\mathit{logical\_actions})$ , an integer. By Definition 10.8, $\mathit{unpaid\_actions}=0$ if and only if $\lfloor\mathit{fee}/\mathit{marginal\_fee}\rfloor\geq m$ . For an integer $m$ and real $x$ , $\lfloor x\rfloor\geq m$ if and only if $x\geq m$ ; and since $\mathit{marginal\_fee}>0$ , $\mathit{fee}/\mathit{marginal\_fee}\geq m$ if and only if $\mathit{fee}\geq\mathit{marginal\_fee}\cdot m$ , which is the conventional fee of Definition 10.2. □

A transaction with more than $\mathit{block\_unpaid\_action\_limit}=50$ unpaid actions is never included by the recommended algorithm, and nodes MAY drop it, or any transaction with more unpaid actions than a configurable limit (ZIP 317, “Transaction relaying”). A relay policy may set that limit to $0$ ; by Lemma 10.9 it then drops exactly the transactions that pay less than the conventional fee. The conventional fee is therefore the least fee that passes every unpaid-action limit, whatever its value. For example, the migration transaction of §10.2 with $\mathit{logical\_actions}=3$ has one unpaid action at a fee of $10{,}000$ zatoshi.

A logical action is not the unit of the block limits of ZIP 218, “Shielded pool action limits”: these count the sum $\mathit{nSpendsSapling}+\mathit{nOutputsSapling}$ of a block’s Sapling descriptions, not the maximum that Definition 10.1 charges, so paying the conventional fee does not ensure that a transaction fits a given block (Consensus Guide, “A block budget for shielded work”). The limits add no transaction field. ZIP 259, “Rationale for no new transaction format”, refers to a block-level fee contribution that needs no transaction field; no published ZIP specifies that calculation, so it is designed but unspecified (Definition 1.1), and the conventional fee does not depend on it.