This is a simple Monero market-based fee proposal. The main motivations for this… proposal are:
* To substantially simplify the fees and block size calculations. In many ways, simpler is better!
* To remove the need to "predict the future" by assigning a "fair" XMR/USD value. Some other proposals incorporate an implied value based on activity, which I believe is not a safe assumption (activity doesn't determine price). This proposal works for all XMR/USD values.
* To add more predictable scaling parameters.
* To improve privacy.
## Transaction Weight and Size
I will leave it to others to define a transaction's weight. I use weight in my calculations.
_See_ https://github.com/seraphis-migration/monero/issues/44
At the time of writing, consensus seems to be roughly around the following general statement:
> Make the tx weight calculation roughly byte size, where you can still calculate the weight of a tx in an offline context using n inputs, n outputs, and extra len.
This page doesn't further discuss transaction weight. It instead discusses with _what to do after we have a weight_.
This also doesn't conflict with PoWER; it only applies to the direct transaction fee.
## Other Proposals/References
* https://github.com/seraphis-migration/monero/issues/44
* https://github.com/ArticMine/Monero-Documents/tree/master
* https://github.com/ArticMine/Monero-Documents/blob/master/MoneroScaling2025-07.pdf
* https://github.com/monero-project/research-lab/issues/133
## Summary
* Eliminate minimum fee (technically, it lowers it to the smallest XMR unit 1 piconero, or 0.000000000001 XMR).
* Create a small penalty free zone (e.g. 400 kB weight), called the "base space." If blocks stay under this size, miners of those block earn the full tail emission reward of 0.6 XMR.
* Allow miners to grow blocks from that zone to X (e.g. 2x the penalty zone size, in this example 800 kB weight).
* For each 1% of this additional "flex space" that is consumed, miners lose out on 1% of the tail emission. This is a linear penalty. Continuing the example of 400 kB of flex space above the 400 kB base space, a block of 404 kB would yield an issuance reward of 0.594 XMR.
* At point X (e.g. 800 kB), the block reward has decreased to 0. So a 800 kB block in the example would yield an issuance reward of 0 XMR.
* Allow miners to increase the maximum size of the "flex space" by y% per block (e.g. 10% per year).
* Implement a consensus rule to require all transaction fees to be a denomination of a power of e.g. 2 starting from the smallest Monero unit.
## Flex Space Growth
<img width="886" height="484" alt="Image" src="https://github.com/user-attachments/assets/ab91d3ae-c8df-4e0f-8b40-b1249712cc8e" />
We can configure an appropriate flex space growth per block. I believe that a growth value of approximately 10% per year is a good target.
I do not believe that the base space should grow each year, though that could grow as well. An advantage to keeping it the same is that if Monero block space demand decreases over time, the low-cost "spam" potential does not increase.
We cannot predict the future, so we do not now exactly what growth rate is most appropriate. It should be a balance that allows for Monero network growth while still encouraging block efficiency.
I picked an initial flex space equal to the base space. A different value can be chosen if desired, but again, simplicity seemed like a reasonable option here.
## Miner Reward
<img width="1000" height="484" alt="Image" src="https://github.com/user-attachments/assets/7899febf-b455-4224-b1d2-edfb280102c0" />
Miner block reward decreases linearly for each percent of flex space consumed. The example above uses a flex space of 1000 kB.
This provides an incentive for miners to avoid using the flex space unless market conditions are favorable (if fees are high enough).
## Market Competition for Fees
This proposal treats market competition for block space as an advantage. This allows for Monero miners to charge as little as 1 piconero if there is no/low demand. It also allows for uncapped fees if demand for space is high.
The relationship between block space supply, transaction demand, and the XMR/USD price are allowed to dynamically play out in a free mining market.
This proposal still requires fees to be denominated. This improves privacy by requiring wallets to "fit in" at least somewhat. Fees that do not fit into a piconero/weight power of 2 are rejected by consensus rules.
In an efficient market, wallets should use a relatively small number of denominations at a given time, depending on the senders' willingness to pay for priority confirmations. However, allowing a huge range of values (1 to near-infinity) will prevent the Monero network from its users all converging on a single max fee level. The goal here is to achieve a balance that encourages transaction uniformity without requiring a specific, singular fee level (e.g. $0.10, as established by an oracle).
Using a power of 2 retains an incentive to communicate with a miner. A sender could collude with a miner by sending them their transaction at the next highest fee level, and receive a partial rebate if they overpay. Currently, Monero has much larger incentives with larger multipliers. Still, the power of 2 can be reduced to a smaller growth denomination in fees, for example 10% growth between denominations, if miner collusion is not adequately discouraged with this power of 2 proposal.
power | picos | XMR | USD@330
-- | -- | -- | --
0 | 1 | 1E-12 | $ 0.00
1 | 2 | 2E-12 | $ 0.00
2 | 4 | 4E-12 | $ 0.00
3 | 8 | 8E-12 | $ 0.00
4 | 16 | 1.6E-11 | $ 0.00
5 | 32 | 3.2E-11 | $ 0.00
6 | 64 | 6.4E-11 | $ 0.00
7 | 128 | 1.28E-10 | $ 0.00
8 | 256 | 2.56E-10 | $ 0.00
9 | 512 | 5.12E-10 | $ 0.00
10 | 1024 | 1.024E-09 | $ 0.00
11 | 2048 | 2.048E-09 | $ 0.00
12 | 4096 | 4.096E-09 | $ 0.00
13 | 8192 | 8.192E-09 | $ 0.00
14 | 16384 | 1.6384E-08 | $ 0.00
15 | 32768 | 3.2768E-08 | $ 0.00
16 | 65536 | 6.5536E-08 | $ 0.00
17 | 131072 | 1.3107E-07 | $ 0.00
18 | 262144 | 2.6214E-07 | $ 0.00
19 | 524288 | 5.2429E-07 | $ 0.00
20 | 1048576 | 1.0486E-06 | $ 0.00
21 | 2097152 | 2.0972E-06 | $ 0.00
22 | 4194304 | 4.1943E-06 | $ 0.00
23 | 8388608 | 8.3886E-06 | $ 0.00
24 | 16777216 | 1.6777E-05 | $ 0.01
25 | 33554432 | 3.3554E-05 | $ 0.01
26 | 67108864 | 6.7109E-05 | $ 0.02
27 | 134217728 | 0.00013422 | $ 0.04
28 | 268435456 | 0.00026844 | $ 0.09
29 | 536870912 | 0.00053687 | $ 0.18
30 | 1073741824 | 0.00107374 | $ 0.35
31 | 2147483648 | 0.00214748 | $ 0.71
32 | 4294967296 | 0.00429497 | $ 1.42
33 | 8589934592 | 0.00858993 | $ 2.83
34 | 17179869184 | 0.01717987 | $ 5.67
35 | 34359738368 | 0.03435974 | $ 11.34
36 | 68719476736 | 0.06871948 | $ 22.68
37 | 1.37439E+11 | 0.13743895 | $ 45.35
38 | 2.74878E+11 | 0.27487791 | $ 90.71
39 | 5.49756E+11 | 0.54975581 | $ 181.42
40 | 1.09951E+12 | 1.09951163 | $ 362.84
## Initial Space Sizes
I am using the following rough values to estimate the Monero conditions with FCMP++:
* Transaction weight: 10 kB
* Free space: 400 kB
* Initial penalty space: 400 kB
| Year | Free Space Txs | Penalty Space Txs | Max Txs | Min Fee/Penalty Tx |
| --- | --- | --- | --- | --- |
| 0 | 40 | 40 | 80 | 0.015 XMR |
| 1 | 40 | 48 | 88 | 0.013 XMR |
| 2 | 40 | 57 | 97 | 0.011 XMR |
| 10 | 40 | 167 | 207 | 0.004 XMR |
| 20 | 40 | 498 | 538 | 0.001 XMR |
| This Many Tx/Blocks | Yield this Many Tx/Day | or this Many Tx/Year | Block Size |
| --- | --- | --- | --- |
| 40 | 28,800 | 10,512,000 | 400 kB |
| 80 | 57,600 | 21,024,000 | 800 kB |
| 88 | 63,360 | 23,126,400 | 880 kB |
| 97 | 69,840 | 25,491,600 | 970 kB |
| 207 | 149,040 | 54,399,600 | 2070 kB |
| 538 | 387,360 | 141,386,400 | 5380 kB |
| 1000 | 720,000 | 262,800,000 | 10000 kB |
| 2500 | 1,800,000 | 675,000,000 | 25000 kB |
Monero transactions per day in 2025: 15,000 to 45,000
Bitcoin transactions per day in 2025: 255,000 to 645,000.
Starting with a larger flex space may be preferable to some, but please keep in mind that:
1. 10 kB is likely an overestimate for FCMP average transaction weight
2. This basic calculation assumes that Monero transactions are about 25x larger (more costly) than Bitcoin transactions.
3. Money finds a way. If fees become expensive, this will encourage innovation for and increase demand for L2s and bridging.
4. The larger you permit the growth, the more challenging it becomes to run a node.
## Potential Enhancements
A more complicated model could look back at how full the last X blocks' flex spaces were, for example 3 months. If they are over 90% full (or a similar value), then an additional growth rate could be permitted. If they are less than e.g. 10% full, then the flex space could decrease. Personally, I think this complexity will cause more problems than it helps. However, allowing the flex space to _decrease slightly_ if it is not used for a long period of time could serve as a useful tool to discourage spam in an environment where XMR has low value.
---
If you want me to provide estimates for other variables, please let me know!
lol
