I was experimenting with it trying to make a version of it lol soon as i saw the post got a couple different versions I’ll put them up on my GitHub soon just normal contribution
4 Likes
5 Likes
(post deleted by author)
@Otr437 I went ahead and ran your code:
=== Zcash Dynamic Fee Mechanism - Complete Implementation ===
Configuration:
Target actions: 50
Max actions: 100
Initial base fee: 1000 zatoshis/action
Fee change rate: 1/8 = 12.50%
=== Simulating Network Activity ===
Day 1: Normal activity
Mempool: 8 tx, 48 actions
Block mined: 8 tx, 48 actions
Fees burned: 48000 zatoshis (0.00048000 ZEC)
Miner revenue: 312514400 zatoshis (3.12514400 ZEC)
Day 2: Network surge (high demand)
Mempool: 40 tx, 214 actions
Block 2 mined:
Transactions: 19
Actions: 99 (198.0% of target)
Base fee: 995 -> 1116 (+12.16%)
Base burned: 98505 zatoshis (0.00098505 ZEC)
Priority fee: 68680 zatoshis (0.00068680 ZEC)
Mempool remaining: 21 tx, 115 actions
Block 3 mined:
Transactions: 18
Actions: 97 (194.0% of target)
Base fee: 1116 -> 1247 (+11.74%)
Base burned: 108252 zatoshis (0.00108252 ZEC)
Priority fee: 50910 zatoshis (0.00050910 ZEC)
Mempool remaining: 3 tx, 18 actions
Block 4 mined:
Transactions: 3
Actions: 18 (36.0% of target)
Base fee: 1247 -> 1148 (-7.94%)
Base burned: 22446 zatoshis (0.00022446 ZEC)
Priority fee: 7740 zatoshis (0.00007740 ZEC)
Mempool remaining: 0 tx, 0 actions
Block 5 mined:
Transactions: 0
Actions: 0 (0.0% of target)
Base fee: 1148 -> 1005 (-12.46%)
Base burned: 0 zatoshis (0.00000000 ZEC)
Priority fee: 0 zatoshis (0.00000000 ZEC)
Mempool remaining: 0 tx, 0 actions
Day 3: Activity normalizes
Block 6 mined: 7 tx, 35 actions
Base fee adjustment: 1005 -> 968 (-3.68%)
=== Fee Estimation Examples ===
Small shielded transfer (5 actions), low priority
Actions: 5
Priority: Low
Base fee: 0.00003250 ZEC
Priority fee: 0.00000160 ZEC
Total: 0.00003410 ZEC
Confidence: 50.0%
Small shielded transfer (5 actions), high priority
Actions: 5
Priority: High
Base fee: 0.00003250 ZEC
Priority fee: 0.00000650 ZEC
Total: 0.00003900 ZEC
Confidence: 50.0%
Large transaction (20 actions), medium priority
Actions: 20
Priority: Medium
Base fee: 0.00013000 ZEC
Priority fee: 0.00001300 ZEC
Total: 0.00014300 ZEC
Confidence: 50.0%
Very large transaction (50 actions), urgent
Actions: 50
Priority: Urgent
Base fee: 0.00032500 ZEC
Priority fee: 0.00009750 ZEC
Total: 0.00042250 ZEC
Confidence: 50.0%
=== Blockchain Statistics ===
Total blocks: 6
Total transactions: 55
Avg transactions/block: 9.17
Avg actions/block: 49.50
Fee Statistics:
Total base fee burned: 312378 zatoshis (0.00312378 ZEC)
Total priority fee to miners: 153980 zatoshis (0.00153980 ZEC)
Total fees: 466358 zatoshis (0.00466358 ZEC)
Burn rate: 66.98%
Miner revenue: 33.02%
Avg fee/transaction: 8479 zatoshis (0.00008479 ZEC)
Current state:
Current base fee: 968 zatoshis/action
Average base fee: 1068 zatoshis/action
Mempool size: 0 transactions
Rejected transactions: 0
=== Fee History (Last 10 Blocks) ===
Height Base Fee Actions Txs Utilization Burned (ZEC)
---------------------------------------------------------------------------
0 1000 48 8 96 % 0.00048000
1 995 99 19 198 % 0.00098505
2 1116 97 18 194 % 0.00108252
3 1247 18 3 36 % 0.00022446
4 1148 0 0 0 % 0.00000000
5 1005 35 7 70 % 0.00035175
=== Economic Analysis ===
Miner Economics:
Block rewards: 1875000000 zatoshis (18.75 ZEC)
Priority fees: 153980 zatoshis (0.00 ZEC)
Total revenue: 1875153980 zatoshis (18.75 ZEC)
Fee % of revenue: 0.01%
Deflationary Impact:
ZEC burned: 0.00312378 ZEC
Effective supply reduction: 0.00312378 ZEC
=== Current Market State ===
Network Status:
Current height: 6
Current base fee: 968 zatoshis/action (0.00000968 ZEC/action)
Mempool Analysis:
Pending transactions: 0
Total pending actions: 0
Avg priority score: 0.00
=== Transaction Type Analysis ===
Type Count Actions Avg Actions/Tx
-------------------------------------------------------
Shielded 26 130 5.00
Mixed 29 167 5.76
=== Fee Strategy Recommendations ===
✓ Fee Market Trend: FALLING
Base fee predicted to decrease ~48.9% over next 3 blocks
Recommendation: Wait for lower fees if transaction is not urgent
=== Simulation Complete ===
Key Insights:
1. Base fee dynamically adjusts based on block utilization
2. Fee burning creates deflationary pressure on ZEC supply
3. Miners earn priority fees + block rewards
4. Users can estimate fees based on desired confirmation time
5. System balances network efficiency with miner incentives
5 Likes
So was it a positive response
2 Likes
I think it’s helpful to get as many ideas and perspectives as possible! Thank you for putting it together.
3 Likes
You welcome I may have a few other things that interest you also seeing how privacy is your specialty
Well if i ever go dark or non responsive its because im without a roof in nyc so i have to hunt for the secure free wifi McDonald’s only allows me two hour to build so hope all is well and it works out i love the idea of privacy because it’s like when you walk by a bank everybody’s bank account isn’t on the front window sliding across like some form of a ticker so I believe crypto should always enact that same privacy feature because it will cripple theft it will be a slight deterrent due to the fact nobody knows anyone’s balance but got to go overstayed my welcome in McDonald’sthis week back to the Wi-Fi hunting enjoy your day every one and always be grateful for all opportunities and acknowledgment remain respectful and share love and show love
9 Likes
Big love!
What’s your UA?
BTW- the design I prefer is no max fee, but a very quick/responsive growth/decay. Here’s why:
Consider two fee designs encountering a few scenarios. One fee design has max fee, and one does not. Let’s call them MAX_FEE and NO_LIMIT_FEE. Both have exponential growth/decay in response to “full” blocks (for some definition, e.g. > threshold action count).
One other assumption I’d like is that all transactions have a relatively short “expiry window”, meaning they are only valid to be mined for ~20 blocks / ~25 minutes. So users will know (or learn if it’s a very consistent standard) that either their txn will succeed within 25 minutes, or it is 100% known to be invalid after that. (This is a best attempt at providing certainty since a high-certainty “cancel button” isn’t possible in a decentralized system.)
With this assumption it’s easier to reason about because there are fewer cases. Without this assumption we have to distinguish between user wallets or preferences to know what their experience might be like, and long expiry times act like Bitcoin and leave users “in limbo” for an unpredictable amount of time.
Scenario A: normal steady state usage or txn spikes that don’t cause the fee to pass the max fee. In Scenario A, the two systems behave identically.
Scenario B: there’s a huge spike in txn demand driven by mostly wealthy users. An example might be that if most Zcash users are global and have relatively modest financial means, whereas there’s an acute wealthy user event (a real life example might be something like the Silicon Valley Bank run where we imagine instead of a bank it’s a crypto exchange, and wealthy traders fear a sudden insolvency). The base fee passes the MAX_FEE threshold. Suppose there is a backlog of 1 day of transactions in the mempool.
In this scenario, the MAX_FEE design begins behaving like a random selection. Since there is a backlog of 1 day while each block is about 75 seconds, so there are typically 24 * 60 * 60 / 75 = 1152 blocks per day. This means all of the transactions which are all paying MAX_FEE have a 1/1152 chance of being included in each block. If each txn expires after about 20 blocks, they get 20 attempts and each time it fails to get into a block, it can make more attempts (until we get to 20), so the chance of retrying right after the 1st block 1 - 1/1152, right after the second block (1 - 1/1152)^2, and the chance of needing to retry when the txn expires after 20 blocks is (1 - 1/1152)^20 = 98.3 \%. This means every user experiences a txn failure 98.3% of the time after waiting 25 minutes, and they have no options or recourse but to just keep retrying.
Meanwhile, in the NO_LIMIT_FEE model, we have to know how quickly fees grow/decay. Let’s say fees grow by 10% per block if blocks are full, and to simplify the comparison, let’s imagine we’re starting exactly when the base fee happens to be MAX_FEE (even though in this design there’s no such special value). After 20 blocks (~25 minutes), the fee is 1.1^{20} = 6.73 times MAX_FEE.
Now we have to ask how many of the ~1 day of backlogged users will retry if the fee is that high. Let’s suppose half of them re-submit. The other half just decides to “wait it out” (we’ll come back to them later). Now after another 20 blocks at that level, the fee is 6.73 * 1.1^{20} = 1.1^{40} > 45 times MAX_FEE! Probably very few remaining users will still be willing to pay this, so again some will wait it out, but there could even be some users that are in some disaster scenario and willing to pay dozens of ZEC to execute a transfer (consider it may be a large business, like an exchange).
In any case, we can see that with this kind of rapidly responsive dynamic fee, almost all users will join the “wait it out” camp within 25-50 minutes. After the users willing to pay astronomical premiums are cleared out, the fee similarly begins falling rapidly. However, there’s still a backlog of users waiting it out, and as soon as the fee falls to a price they are willing to pay, they will pay it.
Eventually the backlog is cleared out. So what happened to users who were only willing to pay MAX_FEE and nothing more? Their experience would be to have thier first txn fail after 25 minutes, then they see the fee spiking, so they wait it out. It will take about a day for the fee to fall back in their range, and then they can submit the transaction and it will go through within ~25 minutes. The difference for them between the two designs is whether or not they have to keep retrying “resend” every 25 minutes for about a half day or so, or whether they just glance at a “current fee” indicator and know with more certainty that it’s either too expensive, or else there’s a good chance their txn will get included.
To me the latter seems like a better UX because those users at least have a much better guess as to what will happen, instead of the unknown of whether or not their txn will get in. Also, consider users with really long time preferences, like suppose during the txn spike some user isn’t in an emergency and just wants to do a txn any time in the next several days and they want to save on fees. This user doesn’t even have to keep monitoring a fee dashboard, they can just go to sleep, eat breakfast, then check again when they’re ready. If a large number of the users in the original 1 day backlog are in this category, then the backlog actually gets cleared out faster, because only the “urgent” users are actively monitoring the fee rate and trying to send as soon as they can afford it.
So what do you think? Is the design with no fee cap more desirable, or maybe “just as good as” a design with the fee cap for users who prefer to pay lower fees?
BTW- there is one other aspect of this design which I like which is no minimum fee, either (except maybe practically 1 Zatoshi)! This way if the blocks haven’t been full for a while, txns are basically free! In the scenario of the giant spike, if we imagine the period before and after the spike blocks aren’t full, then within about a day after the spike starts, fees have returned to close to zero. So even the users only willing to pay almost 0 fees only has to wait a day in that scenario.
And finally, just to echo what @aquietinvestor mentioned above: if we want lower fees on average / over time for a steady txn demand (which I definitely do!) the solution isn’t dynamic fees itself, but scalability improvements. Dynamic fees are just a way to protect the user experience against surges so that their experience is more reliable.
4 Likes
Ahh thanks you for the insight back to the drawing board i guess but it totally makes sense
2 Likes
u160yr8uyyzmts4zxgy6ac7urdyr0vr9s4eaa48hdly6vs3ls9y02msnpt2gygsdrnhflwx2yn75y4krv2jut8gqyejl8v5mtu345ty62pfqw6a0ztza5hmz85wxyjtgqh883dvnkp9kunkr700z7xkgwhn9angwtlv6jpzu0hqstm6fdj
2 Likes
I appreciate you so much whoever that was I appreciate you so so much that led to me being able to pay for my replacement ID and birth certificate I appreciate you so much that was a step in the right direction for me you don’t know how much that helped they steal alot in New York City shelters
Thank you so so much thank you again like a million times over
6 Likes
Transaction fees have risen sharply as ZEC’s price has increased over the past few weeks. At some point, it may make sense for someone to manually update the marginal fee parameter in ZIP 317. As far as I understand, this doesn’t require a consensus change, but it does require coordinated updates across wallets as well as both zcashd and zebrad.
Last week, the Shielded Labs team discussed whether we should take on that work ourselves. After weighing the options, we decided that our resources are better spent pushing forward on a dynamic fee mechanism that can provide a long-term solution to rising fees. We’re moving full speed ahead on that effort, with @shieldedmark and @zooko leading the technical design.
7 Likes
If it’s the direction the community agrees on, Zingo Labs is likely to adapt the marginal transaction fee.
We stand ready.
That means that SL can focus on a more thoughtful mechanism, while we handle any work necessary (for our wallet), for a temporary solution.
2 Likes
I sent nate the version i think he asked for
This version applying the things he asked
2 Likes
It would be good if people could post papers / articles / blog posts that they find relevant to this effort. I’ll start 
A Holistic Approach for Bitcoin Confirmation Times & Optimal Fee Selection
Bitcoin is currently subject to a significant pay-for-speed trade-off. This is caused by lengthy and highly variable transaction confirmation times, especially during times of congestion. Users can reduce their transaction confirmation times by increasing their transaction fee. In this paper, based on the inner workings of Bitcoin, we propose a model-based approach (based on the Cramer-Lundberg model) that can be used to determine the optimal fee, via, for example, the mean or quantiles, and models accurately the confirmation time distribution for a given fee. The proposed model is highly suitable as it arises as the limiting model for the mempool process (that tracks the unconfirmed transactions), which we rigorously show via a fluid limit and we extend this to the diffusion limit (an approximation of the Cramer-Lundberg model for fast computations in highly congested instances). We also propose methods (incorporating the real-time data) to estimate the model parameters, thereby combining model and data-driven approaches. The model-based approach is validated on real-world data and the resulting transaction fees outperform, in most instances, the data-driven ones.
https://arxiv.org/pdf/2402.17474
Note: this is not an endorsement of this particular idea per sé, just something I find interesting.
4 Likes
So if the version I made I was to apply the mathematical equations and things that you recommended in your post would that be more of what you’re looking for like the latest version that I attempted to make I applied that to the latest version would that be satisfactory or would it need more please detail
In my view, to keep Zcash competitive, being similar to or better than the global financial system, the longest transaction time cannot exceed that of a bank transfer (1 to 3 days). Zcash may be remembered as the old Swiss banking system, when many were interested in it because it was a system with privacy and anonymity. If Zcash, with its lowest transaction fee, takes longer than a bank transaction (1 to 3 days), this will make Zcash less competitive. We can make Zcash the financial system of the future, with speed similar to the financial system, anonymity, and the possibility of passive income through staking (optional).
1 Like
There could be a mechanism that would allow users to select both the transaction fee (limited to 1% of the transaction value) and the time limit (adjusted in real time). The user could then select, if possible (limited to 1% of the transaction value), whether they want an instant transaction (the fastest possible time), a transaction every 30 minutes, every hour, etc., up to a maximum of 3 days (with the maximum fee, respecting 1% of the transaction; if they are an advanced user, they could unlock this feature, but without being able to set fees that erode their assets).
A conventional transaction with a maximum processing time of 3 days could have the lowest fee of all, allowing for low transaction values, making a faucet a viable option. There could also be mechanisms in place where, if a single wallet sends several consecutive transactions with very low values, indicating a “span,” the transactions could be rejected for a period of 1 day.
Example: instant transaction fee with a maximum of 1%, 3-day transactions with a maximum of 0.10% of the transaction value. Respecting a minimum fee, paying whichever is greater, 0.10% of the transaction value or a fee of 0.003 zec. This is just an example of what I mean regarding fees.
1 Like