ZIP: 235
Title: Burn 60% of Transaction Fees
Owners: Jason McGee <jason@shieldedlabs.net>
        Zooko Wilcox <zooko@shieldedlabs.net>
        Tomek Piotrowski <tomek@eiger.co>
        Mariusz Pilarek <mariusz@eiger.co>
        Paul Dann <paul@eiger.co>
Original-Authors: Nathan Wilcox
Credits:
Status: Draft
Category: Ecosystem
Created: 2023-09-21
License: BSD-2-Clause
Discussions-To: <https://github.com/zcash/zips/issues/924>

Terminology

The key word “MUST” in this document is to be interpreted as described in BCP 14 ¹ 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. ²

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

The terms “Mainnet” and “Testnet” are to be interpreted as described in § 3.12 ‘Mainnet and Testnet’. ⁴

The symbol “\(\,\cdot\,\)” means multiplication, as described in § 2 ‘Notation’. ⁵

“ZEC/TAZ” refers to the native currency of Zcash on a given network, i.e. ZEC on Mainnet and TAZ on Testnet.

The terms “Block Subsidy”, “Issuance”, and “Burning” are to be interpreted as described in ZIP 233. ⁶

Abstract

This ZIP proposes to burn 60% of transaction fees, while the remaining 40% is directed as before, providing a deflationary effect, and building the groundwork for long-term support of the Zcash network via the new block subsidy rules proposed by ZIP 234 ⁷.

Motivation

ZIP 233 (“Network Sustainability Mechanism: Burning” ⁸) describes a method by which ZEC can be burned to support network sustainability.

By introducing a requirement that a certain proportion of transaction fees be burned, we ensure that ZEC will be removed from circulating supply to contribute to the long-term sustainability of the network as described below:

Benefits to the Network

1. Network Sustainability: This mechanism involves temporarily reducing the supply of ZEC, similar to asset burning in Ethereum’s EIP-1559 ⁹, but with long-term sustainability benefits, as the burned funds effectively boost future mining rewards, making it an attractive option for current and future Zcash users.
2. Incentivizing Transaction Inclusion: By maintaining a 40% share of transaction fees for miners, we continue incentivizing miners to prioritize including transactions in their blocks. This helps ensure the continued efficient processing of transactions and supports a robust and responsive network.
3. Aligning Interests: Burning transaction fees aligns the interests of miners with the long-term health of the network, incentivizing them to prioritize security and efficiency. As miners focus on maintaining a robust network, overall adoption and usage can increase, leading to higher transaction volumes in the long run. This structure discourages short-term profit-seeking behaviors, as miners benefit more from a stable and thriving ecosystem than from engaging in malicious activities that could undermine the network’s reputation and security.
4. Future-Proofing the Network: Burning a portion of transaction fees is a forward-looking approach that prepares the Zcash network for future challenges and opportunities. It establishes a financial buffer that can be instrumental in addressing unforeseen issues and seizing strategic advantages as the Zcash ecosystem evolves.

Requirements

• For each block, at least 60% (rounded down) of the total fees are to be burned.
• No restrictions are placed on the destination of the remaining proportion of fees.
• Any fractions are rounded in favor of the miner.

Specification

Consensus Rule Changes

For a given block, the coinbase transaction MUST have a \(\mathsf{burn\_amount}\), as defined in ¹⁰, that is greater than or equal to \(\mathsf{floor}(\mathsf{transactionFees} \cdot 6 / 10)\).

The version of a coinbase transaction MUST be v6 or later ¹¹.

Applicability

All of these changes apply identically to Mainnet and Testnet.

Rationale

We believe the proposed changes to be relatively low-impact in terms of implementation and protocol changes. Additionally, transaction fees are currently small enough that the reduction in miner fees is unlikely to be a concern.

Rationale for requiring the coinbase transaction to be v6 or later

There is no explicit mechanism in prior transaction versions to burn the required funds. Since \(\mathsf{burn\_amount} = 0\) for transaction versions prior to v6, absent the rule about the coinbase transaction version it would be technically possible to satisfy the constraint on \(\mathsf{burn\_amount}\) with earlier versions than v6, but only when \(\mathsf{transactionFees} = 0\). That would introduce a corner case in the transaction consensus rules that is not useful, since it is expected that the \(\mathsf{transactionFees}\) will normally be non-zero.

Estimated impact on miners

Over 100,000 blocks starting at block 2235515, there were 316130 transactions. 60608 of them are categorized as ‘sandblasting’ transactions. The remaining transactions have an average of 5.46 logical actions (see ZIP 317 ¹²).

The total fees paid to miners from those transactions, assuming the ZIP 317 regime, would be 87.86 ZEC. 100,000 blocks is approximately 3 months of blocks. Extrapolating to a year, we would expect 351.44 ZEC in fees paid to miners over a year.

If 60% of these fees burned, that would be 210.864 ZEC per year. ¹³

Considerations for the Future

If transaction fees were to increase, further modifications can easily be proposed to alter the 60%/40% split. Finding the optimal fee split may require an iterative approach involving adjustments based on real-world data and network dynamics.

Looking further into the future, there may come a time when the transaction fees become greater than the block subsidy issuance. At that time we may need to reconsider the 60/40 split. However, this will likely not be the case for the next 8-10 years due to forecasts based on issuance models and network traffic.

Further ZIPs may be proposed to burn ZEC in various ways to support network sustainability, including but not limited to:

• ZSA fees
• Fees and donations specific to decentralized applications
• “Storage fees” for any future data availability
• Cross-chain bridge usage / Cross-chain messaging
• Note sorting micro-transactional fees

Deployment

The implementation of this ZIP MUST be deployed at the same time or after ZIP 233 (“NSM: Burning” ¹⁴), and ZIP 234 (“NSM: Issuance Smoothing” ¹⁵).

References