ZIP: 2002
Title: Explicit Fees
Owners: Daira-Emma Hopwood <daira@jacaranda.org>
        Kris Nuttycombe <kris@nutty.land>
        Jack Grigg <thestr4d@gmail.com>
Credits: Simon Liu
Status: Draft
Category: Consensus
License: MIT
Discussions-To: <https://github.com/zcash/zips/issues/803>
Pull-Request: <https://github.com/zcash/zips/pull/919>

Terminology

The key word "MUST" in this document is to be interpreted as described in BCP 14 1 when, and only when, it appears in all capitals.

The term "network upgrade" in this document is to be interpreted as described in ZIP 200. 7

The character § is used when referring to sections of the Zcash Protocol Specification. 2

The terms "Mainnet" and "Testnet" are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. 4

Abstract

This proposal makes the transaction fee explicit in the v6 transaction format, as an entry in the transparent transaction value pool balance map defined in ZIP 248 10. 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.

Motivation

When it comes to fee selection, it should be very hard to make mistakes. The current transparent fee computation (inherited from Bitcoin) — input value less output value — is prone to user error. It is very easy to forget to add an output for a change address, make a calculation error 6, mix up units etc.

In addition, when signing a transaction with a hardware wallet, using an implicit fee means that the hardware wallet must recompute the fee on its own and cannot simply display the value being committed to.

Finally, this change will make it possible for light clients to determine the fee paid by a transaction without needing to download and inspect transparent inputs to the transaction.

Requirements

Parties that see a transaction, even in isolation, reliably know its fee. That is, the fee must be explicit in the encoding of the transaction, and no potentially error-prone calculations or additional chain data are needed to compute it.

Specification

Changes to ZIP 248

This ZIP proposes to register bundle type 4 variant 0 ("Transaction fee") in the V6 transaction bundle type registry defined in ZIP 248 10.

BundleType BundleVariant mValuePoolDeltas mEffectBundles mAuthBundles
4 0 ✅ ❌ ❌

The fee bundle has no effecting data and no authorizing data. The transaction fee is represented solely as an entry in mValuePoolDeltas with bundleType = 4 and assetClass = 0 (ZEC).

For non-coinbase transactions, the value field of this entry MUST be nonpositive, representing the fee being removed from the transparent transaction value pool. For coinbase transactions, the value field MUST be nonnegative, representing the total fees collected from other transactions in the block being added to the ZEC transparent transaction value pool.

Changes to the Zcash Protocol Specification

Let \(\mathsf{FeeBundleId} = 4.\)

Let \(\mathsf{Zec}\) be the asset UUID for ZEC as defined in ZIP 248 10.

In § 3.4 'Transactions and Treestates' 3 (last modified by ZIP 236 9), add the following consensus rules:

  • [NU7 onward] The assetClass for any entry in mValuePoolDeltas having bundleType \(= \mathsf{FeeBundleId}\) MUST be 0. That is, fee amounts MUST be denominated in ZEC.
  • [NU7 onward] For v6 and later non-coinbase transactions, the value of \(\mathsf{mValuePoolDeltas}[(\mathsf{FeeBundleId}, \mathsf{Zec})]\) MUST be nonpositive. Its absolute value represents the transaction fee in zatoshis.
  • [NU7 onward] For v6 and later coinbase transactions, the value of \(\mathsf{mValuePoolDeltas}[(\mathsf{FeeBundleId}, \mathsf{Zec})]\) MUST be nonnegative. It represents the total transaction fees collected from all other transactions in the block.

In § 7.1 'Transaction Encoding and Consensus' 5, add:

[NU7 onward] The absolute value of the fee bundle's value pool delta MUST be in the range \(\{ 0 .. \mathsf{MAX\_MONEY} \}\!\) .

Modifications to Digest Algorithms

The fee amount is committed to the transaction identifier and signature digest via the value_pool_deltas_digest defined in ZIP 248 10. Since the fee bundle (bundle type 4) has no effecting data and no authorizing data, its only contribution to the transaction digest is through its entry in mValuePoolDeltas.

Applicability

All of these changes apply identically to Mainnet and Testnet.

Deployment

This ZIP is proposed to be deployed with the next transaction version change, which is assumed to be v6. 8

Reference implementation

TBD

References

1 Information on BCP 14 — "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels" and "RFC 8174: Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"
2 Zcash Protocol Specification, Version 2025.6.2 [NU6.1] or later
3 Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 3.4: Transactions and Treestates
4 Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 3.12: Mainnet and Testnet
5 Zcash Protocol Specification, Version 2025.6.2 [NU6.1]. Section 7.1.2: Transaction Consensus Rules
6 Bitcoin Forum post by @Voiceeeeee, March 8, 2017. "PLEASE HELP.. I sent a transaction with a 2.5 BTC transaction fee"
7 ZIP 200: Network Upgrade Mechanism
8 ZIP 230: Version 6 Transaction Format
9 ZIP 236: Blocks should balance exactly
10 ZIP 248: Extensible Transaction Format