As of writing this the transaction fees are 0.01 XMR per KB. This was a reasonable fee when Monero was worth less, however, if XMR retains it's new found value or continues to rise in value against BTC or USD that transaction fee could prevent some users from adopting or using Monero as a currency.

When fees are high it's likely less transactions will occur which may lead to less adoption.

Are there any fair ways to dynamically adjust the transaction fee per KB based on an algorithm? If not, how can they be adjusted on a more frequent basis than once every 6 months during a fork?

3 Answers 3


First of all, minimum fee doesn't require a fork. It's a network-enforced rule, and if some % of nodes would relax the fee requirements, you'd have a chance of having a lower fee transmitted to some miner who could include the TX in some block. Of course, firstly you'd have to tweak the wallet to create a TX with a lower fee than what's hard-coded into the wallet.

The fees are now dynamic, as explained here. The lowest possible setting is the minimum fee, and other, higher-priority settings are a multiplier of that. To sum it up, available fee multipliers are:

x1 (minimum fee, low priority), x4 (default), x20 and x166

There's a small set of possible fees to maintain privacy. If I used a custom fee, you could compile a list of TX-es which use some special fee and assume they are likely to belong to one single entity.

In words, the minimum fee could be defined as:

Fee such that, given a pool of TX-es offering minimum fee, the best strategy for the miner would be to mine a block at 100.6% of the current blocksize median, ie an 0.6% increase (actually anything between 0% and 1.2% would be economic, and 0.6% is just the "sweet spot").

In a mixed pool, it is always the smallest fee TX to get in a block which determines the optimum %. If there's enough higher fee TX-es, they'd kick out the small ones until the blocksize catches up with increased demand and makes room for those.

The x4 multiplier then means a 2.4% increase which is just enough to economically squeeze 1 typical TX above the min. blocksize, x20 one a 12% increase, and the extreme x166 one a 100% increase.

This means that the fee will go down with both time (due to reducing block emission) and increased usage (due to increasing blocksize). If the price grows linearly with usage (blocksize), the fees will remain constant in terms of fiat price.

There was a hiccup with this system when the TX size was increased with RCT HF, but nothing was done with the blocksize so TX-es became too big relative to min. blocksize and caused a congestion. This happened because adding just 1 TX over the median would have meant a 23% blocksize increase, requiring huge fees to be economic for the miner. Because of this, the min. blocksize was increased in the April 2017 HF.

With the current ratio of typical TX size and min. blocksize we should be fine "forever". The upcoming range proof size reduction will only help this as it will drive the ratio further down. Once the network organically "permanently" pushes the median blocksize above the min. blocksize, it will only get better and better and the dynamic fee/blocksize combo would be working more and more smoothly.


Dynamic fees currently do not exist yet and currently the fee is hardcoded at 0.01 XMR per KB. There is a lot of discussion on how to address this subject and core-team member ArticMine is looking into it. However, given that there is nothing concrete yet, it is not possible currently to answer your question.

One thing I've seen discussed is looking at the median blocksize as indicator of transaction volume. Intuitively, a higher median block size equates higher usage (transaction volume). In Bitcoin, as can be seen from here, the price is positively and strongly correlated with transaction volume. Therefore, this is one method that could work. However, it should be noted that the correlation in Monero is currently less strong than in Bitcoin. Although, this correlation will probably increase now that there is real-world demand for Monero (most notably darknetmarkets).


With any dynamic adjustment you have to remember that the only trustworthy source of information is the blockchain itself. Having trusted oracles indicate the current market price, or similar, is just a centralisation vector that is best avoided.

Currently, basing it on transaction volume is about the best idea we have, but there's a lot of work to do in order to get that to a usable point.

  • What about letting this setting adjustable by every node, any node can adjust its minimum relay fee. The result will let the network find its minimum fee in a decentralised manner?
    – ant Bldel
    Sep 8, 2016 at 7:44
  • 1
    @antBldel Monero doesn't need a fee market because of the dynamic block limiter. But it does need a minimum fee to prevent spam. Sep 8, 2016 at 8:47
  • 1
    Sorry if this is dumb, but isn't it possible to achieve spam control with PoW? I believe that's the original PoW use-case, and if this could work and xaction fees dropped entirely then it would be a killer feature on its own.
    – avnr
    Sep 8, 2016 at 16:58
  • 1
    @avnr sure you can, so then you make it computationally expensive to create a transaction. But do we really want transactions that create 60 seconds to create just to prevent blockchain spam? :-P Sep 8, 2016 at 19:54
  • 1
    I appreciate your last sentence, yet am still toying with the immense marketing power of "free" transactions. If the transaction reward for miners were less than the amount that can be mined with the PoW difficulty, then the miners can be rewarded even if the client didn't pay a fee, a kind of inflationary tax (that has nice marketing returns) on holders of the coins. Let the client decide whether to pay a fee or do a PoW. The big boys will mine coins and pay their fees, the sporadic client who cannot cash out a fraction of a coin for a single transaction will do a PoW and get a fee subsidy.
    – avnr
    Sep 10, 2016 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.