Recomputing the conventional Zcash transfer fee from a transaction shape you declare: counts and byte sizes go in, one integer fee in zatoshi comes out, and every step is arithmetic you can redo by hand from the published rule.
The conventional fee is one number times one count: 5000 zatoshi per logical action, never less than two actions' worth.
The floor is the grace window. It exists so that adding a second input or output for privacy padding never raises the fee: a one-action shape and a two-action shape pay the same. The recompute applies exactly this formula to the shape you declare; it says nothing about what any wallet or miner will accept.
If a transaction declares 4 Orchard actions and nothing else, what conventional fee does the published rule yield?
The logical action count is a sum of four contributions, one per pool, each derived from the shape you declare.
| Pool | Contribution to logical_actions | Declared input |
|---|---|---|
| Transparent | max(ceil(tx_in_total_size / 150), ceil(tx_out_total_size / 34)) | byte totals of the transparent inputs and outputs |
| Sprout | 2 x n_joinsplit | number of JoinSplits |
| Sapling | max(n_spends_sapling, n_outputs_sapling) | numbers of spends and outputs |
| Orchard | n_actions_orchard | number of actions |
The transparent pool is counted in whole standard-sized units, so byte totals round up: a 151-byte input total spans two units. Sapling takes the greater of its two sides, not the sum, because a payment spends one note and creates another. Absent pools contribute zero.
A transaction declares 150 bytes of transparent inputs, 68 bytes of transparent outputs, and nothing else. How many logical actions is that?
One declared shape touching all four pools, recomputed line by line; the node emits exactly the last row.
| Declared input | Value | Contribution |
|---|---|---|
| tx_in_total_size | 300 bytes | ceil(300/150) = 2 |
| tx_out_total_size | 34 bytes | ceil(34/34) = 1, so transparent = max(2, 1) = 2 |
| n_joinsplit | 1 | 2 x 1 = 2 |
| n_spends_sapling / n_outputs_sapling | 1 / 2 | max(1, 2) = 2 |
| n_actions_orchard | 1 | 1 |
| logical_actions | 2 + 2 + 2 + 1 | 7 |
| conventional_fee_zatoshi | 5000 x max(2, 7) | 35000 |
Change any declared value and the arithmetic moves with it: this is a recompute of a published formula, not a lookup table. The node's own output payload carries the four contributions, the action count, whether the grace floor bound, and the fee, so each intermediate is checkable against this table.
Recompute the conventional fee for: tx_in_total_size 300, tx_out_total_size 34, n_joinsplit 1, n_spends_sapling 1, n_outputs_sapling 2, n_actions_orchard 1.
The fee the rule yields for a declared shape is one thing; whether any wallet, miner, or node accepts that fee is a different thing, and this node claims only the first.
The output is the fee the published conventional formula yields for the declared shape. It is not a prediction of acceptance, not a recommendation to transact, and not coin marketing.
The input is counts and byte totals only. No viewing key, no spending key, no address, no raw transaction: a string in a declared numeric field is refused and never echoed.
The recompute implements the fee rule revision in effect today. Contributions defined only by later drafts, such as extra action pools or memo bundles, are refused rather than guessed at.
Negative, fractional, or beyond-exact-integer counts and sizes are refused: they are not declared transaction shapes. Absent pools contribute zero.
Every refusal is a structured non-verdict naming the branch, each with its own reachable input and fixture; nothing refuses silently. The formula text itself states that following it is not a consensus requirement: wallets should create transactions that pay this fee to reduce information leakage, unless the user overrides.
What does this node refuse, and why does it refuse rather than estimate when a shape declares a draft-revision pool?