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 the simplest mechanism we could think of 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.
This is not intended to be the final design, just a starting point for discussion.
The core idea is to create a true market where users pay fees based on recent transaction history, adjusted for congestion.
It turns out, then, that the most useful data is already public (goal #2): the prices people have been willing to pay in the recent past for fees, often called comparables.
Comparable-based pricing is incredibly common and is used in countless markets: collectibles, art auctions, real estate, and more. The concept is generally easy to understand and explain (goal #3.1).
Here's how it works:
We compute baselines from the last hour or so (typically 50 blocks). However, the chain tip can be somewhat volatile due to reorg noise, so we guard against this with a 5 block buffer. This establishes our lookback window 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.
We define the standard price as the median fee per action from the lookback window, taking into account the synthetic transactions.
The median is an extremely useful statistic here, as we can be reasonably confident that a transaction will confirm within the next ~50 blocks (goal #3.3), even as the blocks fill with authentic transactions.
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)
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).
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 standard fee (goal #3.4). Once the congestion eases, the standard 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 standard 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.
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.
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.