Transaction fees, whether high or low, affect Zcash users in many ways. Let's explore dynamic fee mechanisms past, present, and future together with the goal of keeping Zcash affordable, reliable, and private for all users.
Before reading the proposal, it's helpful to understand the historical context of Zcash transaction fees.
Fees began at 10,000 zatoshi, and later shrunk to 1,000. These low, fixed fees were celebrated as a core part of ZEC’s value-prop and onboarding:
“I personally share my Z-addr from time to time on Twitter and I get flooded with messages from the community. It’s really a special experience. I’ve also onboarded 100+ people in this way through a simple message and a few cents in Zcash.” - Forum Thread
However, low fixed fees eventually enabled "sandblasting" episodes which flooded the chain with transactions containing an enormous amount of shielded notes, filling disks and bricking wallets via overprocessing.
In response, ZIP-317 introduced the actions abstraction, consolidating transparent inputs/outputs, Sprout JoinSplits, Sapling spends/outputs, and Orchard actions into a single accounting unit.
ZIP-317 is generally credited with ending sandblasting, and remains the current fee mechanism on mainnet.
Now (late 2025 / early 2026), Zcash is finally having its day in the sun: ZEC’s price is surging, self-custody interest is up thanks to "the Zashi effect." Also, the emergence of multiple Zcash Digital Asset Treasuries and a potential spot ETF on the way signal institutional support. All signs point to increased adoption, volume, and attention.
While there is still no conclusive evidence of users outright refusing to transact because of fees, cracks may be starting to show.
Now may be the time to act on dynamic fees given the rising price, adoption, and attention.
A successful design and implementation is one that:
Two immediate, obvious considerations are:
Several prior proposals and mechanisms have addressed dynamic fees in blockchain networks:
Each of these prior mechanisms has strengths and weaknesses that we can draw inspiration from, while tailoring a solution specifically for Zcash's unique requirements.
Here is a mechanism that satisfies the above goals and principles, builds directly upon ZIP-317's action-based accounting and takes into account all of the above context.
Disclaimer: This is not intended to be the final design, just a starting point for discussion.
A fee market is a mechanism where prices are determined by availably block space and transaction volume, driven by discretionary choices of users and miners (goals #3.1 and #4).
The market mechanism can be informed by public data (goal #2): the prices people have been willing to pay in the recent past for fees, often called comparables. Users are given a choice to pay a marginal fee based on a median calculation of recent comparables, or a priority fee when there is competition for block space (goal #3.4).
Comparable-based pricing is a well-studied and widely applied mechanism used in collectibles, art auctions, real estate, and more (goal #3.1).
Instead of a fixed marginal fee per action as in ZIP-317, the marginal fee is computed dynamically based on the median per-action fee from a lookback window of 50 recent blocks (roughly one hour). The computation is based on two statistics from the lookback window:
The chain tip can be somewhat volatile due to reorg noise, so a 5-block buffer is applied as a guard. The lookback window is defined as the last 50 blocks after the 5 block buffer.
To simplify our reasoning, we model the network as always congested by filling it with synthetic transactions at the average size and a chosen minimum floor price. This floor can be very low, as we plan to adjust it upward when the network is congested.
ZIP-317 still helps here, preventing an attacker from purposely generating large-in-kb transactions to tamper with the fee market.
The marginal fee is the median fee per action from the lookback window, taking into account the synthetic transactions.
The median, where over half of transactions pay at least this much, gives us a reasonable assurance that a transaction will confirm within the next ~50 blocks (goal #3.3), even as the blocks fill with authentic transactions.
Instead of using the raw median fee per action, we can bucket it to the nearest power of ten. For example, if the median fee per action is 32,000 zats, we would round down to 10,000 zats; if it were 78,000 zats, we would round up to 100,000 zats.
By rounding fees to the nearest power of ten (as ZIP-317 suggests), we can greatly reduce fee entropy, information leakage, and linkability. (goal #1). It's also easier for the user to understand due to fewer significant digits (goal #3.1).
The floor price should be divisible by 5 so that we can recycle 60% of transaction fees back to issuance as per the Network Sustainability Mechanism ZIP-235. (goals #7.1 and #6.2)
Coarse bucketing has the added benefit of making fee changes rare (goal #3.2).
The median fee per action will naturally rise (goal #5) as real transactions outcompete synthetic ones. However, when there is no more room for a single synthetic transaction in the lookback window. At that point, our reasonable confidence that a transaction will confirm within ~50 blocks begins to erode due to increasing mempool pressure.
To provide a way for users to prioritize their transactions when the network is congested, we can temporarily open a "fast lane" with a fee multiplier of 10x the marginal fee (goal #3.4). Once the congestion eases, the marginal fee will lower, and the "fast lane" will close.
From there, miners are expected to act in their own self-interest by including higher-fee transactions first (goal #4), while users can choose to pay the marginal fee or the priority fee based on their needs.
Between this and ZIP-317's action-based accounting, griefing attacks should become expensive enough to deter attackers (goal #6).
This mechanism can be rolled out in phases (goal #7.2):
Moving forward, we'll perform threat modeling of spam, MEV-style shenanigans, and privacy leak vectors, then run long-horizon simulations to see how these mechanisms behave under sustained stress and shifting demand.
Additionally, we will document all known trade-offs and edge cases to ensure a comprehensive understanding of the proposal's implications.
In the meantime, we are actively seeking feedback from the Zcash community, developers, and stakeholders on this proposal. Your insights and suggestions are invaluable as we refine and enhance the dynamic fee mechanism.
Please share your thoughts on the Zcash Community Forum or reach out directly to the Shielded Labs team.
Together, we can ensure that Zcash remains a robust, user-friendly, and privacy-focused blockchain for years to come.
In addition to the main proposal, we are exploring other ideas that could complement or enhance the dynamic fee mechanism:
From @str4d:
An interesting observation is that Zcash mining difficulty may serve as a rough proxy for USD price.
Difficulty and USD price move together in this sample (Pearson r ≈ —), which is intriguing, but we need longer windows across bull and bear regimes to see if the relationship is persistent or just cyclical.
Daily % changes are only weakly correlated (r ≈ —), so day-to-day difficulty moves tell us almost nothing about day-to-day price moves.
This is also bounded to the availability of ASIC hardware, which is a serious constraint on how quickly difficulty can adjust to price changes.
The Cramér-Lundberg model is a mathematical framework used in risk theory and actuarial science to model the surplus of an insurance company over time. It helps in understanding the probability of ruin and the behavior of reserves under random claims and premium income.
In the context of dynamic transaction fees, we can adapt the Cramér-Lundberg model to tune fees based on real-time mempool conditions. By modeling the arrival rate of transactions (claims) and the processing capacity of the network (premium income), we can adjust fees to maintain a target confirmation time.
This approach allows us to dynamically respond to congestion by increasing fees when the mempool is full and decreasing them when it is empty, aiming to keep transaction confirmation times within a desired range.