Monero Tail Emission: What 0.6 XMR per Block Really Pays For

The number first. Between 10:00 UTC on 25 October and 10:00 UTC on 26 October 2026 we pulled 720 consecutive Monero blocks, heights 3,791,729 to 3,792,448, and added up every coinbase output. Miners earned 438.5282 XMR. Exactly 432 of that was the fixed block subsidy; 6.5371 XMR was transaction fees. Fees were 1.491% of miner revenue for a full day, and 235 of the 720 blocks took in less than 0.5% of their reward in fees. That single ratio is the whole argument about Monero's long-term security budget, so it is worth knowing exactly what is inside it. (how Monero fees work)

Where 0.6 XMR per block comes from. It is not a governance decision renewed each year; it is a floor in the emission formula. In `cryptonote_config.h` of Monero v0.18.5.4, `FINAL_SUBSIDY_PER_MINUTE` is 3 x 10^11 piconero, i.e. 0.3 XMR per minute. The subsidy is `(MONEY_SUPPLY - already_generated) >> 20` per minute, and the code clamps it to that floor once the shift produces less than 0.3 XMR. At a 120-second block that is 0.6 XMR, forever. Solving the same formula gives the supply at which the floor starts binding: (2^64 - 1) piconero minus 0.3 x 2^20 XMR, or 18,132,171 XMR. The first block whose base reward was floored is height 2,641,605, timestamped 2022-06-08 23:59:31 UTC. Since then: 432 XMR a day, 157,680 a year, no halvings and no end date.

The subsidy is a floor, not a curve. Monero has no halving schedule left and no cap. The 18.44 million figure people quote is not a supply limit; it is 2^64 piconero, the width of the integer field, and `MONEY_SUPPLY` in the source is literally `(uint64_t)(-1)`. Inflation falls anyway, because the numerator is constant while the denominator grows: with supply at 18,822,617 XMR on 26 October 2026, 157,680 new coins a year is 0.838%, dropping to 0.773% in ten years and 0.669% in thirty. It approaches zero and never arrives there. That is the trade Monero made in 2022: permanent small inflation in exchange for a permanent, predictable security budget.

A day's ledger: 438.53 XMR in, 6.54 from fees. The same 720 blocks carried 26,936 transactions, 37.4 per block, with a maximum of 171 and 35 completely empty blocks (4.9%). Average fee per transaction was 0.00024269 XMR, about 14 cents at the $588.61 spot price we recorded at 10:00 UTC. The median block's average fee was 0.00019326 XMR (11 cents) and the 90th percentile was 0.0004398 XMR (26 cents). Fee share per block had a median of 0.96%, a 90th percentile of 3.74% and a maximum of 12.24%; 36 blocks took more than 5% of their reward in fees. And the revenue is lumpy: the busiest 10% of blocks produced 38.2% of all fees in the day. (how Monero fees work)

Fees are priced per byte, not by tipping. Monero's fee estimate is a posted price list, not an auction. On 26 October our node returned four tiers - 20,000, 80,000, 320,000 and 4,000,000 piconero per byte - with a 10,000-piconero quantisation mask. At the base tier one byte costs 0.00000002 XMR. A one-input, two-output spend of 1,534 bytes pays 0.00003068 XMR (1.8 cents); a two-in, two-out spend of 2,220 bytes pays 0.0000444 XMR (2.6 cents); the 4x tier on the same 2,220 bytes pays 0.0001776 XMR (10.5 cents). You are buying kilobytes at a listed rate. Miners do sort by fee per byte, but sorting only decides anything when more transactions want a block than fit in it. (how Monero fees work)

Block space is 13.8% used, and that caps the whole fee market. Median block weight in the sample was 59,476 bytes - 9.9% of the 600 kB limit - with a 90th percentile of 274,980 and a maximum of 321,689. Total space consumed was 68.35 MB against a 432 MB ceiling: 15.8% utilisation across 24 hours, with an average block interval of 120.54 seconds against a 120-second target. At 2,220 bytes per transaction, a full block holds about 270 transactions, or 194,595 a day; the chain actually processed 26,936, which is 13.8%. Demand would have to grow roughly 7.2 times before the fee tiers became a rationing device rather than a price list. (how Monero fees work)

Full blocks cost the miner money, on purpose. `get_block_reward()` floors the median weight at 300,000 bytes and then penalises weight above it: the reward is multiplied by `(2m - w) x w / m^2`, and a block above `2m` - 600 kB in practice - is rejected outright. We saw 59 blocks over 300 kB in the day. The heaviest, 321,689 bytes, lost 0.52% of its reward; the penalty across all 59 came to 0.0089 XMR, or 0.002% of the day's issuance. This is the mechanism that keeps Monero's blockspace from being filled by spam: making a block fuller than the median costs the miner directly, so nobody profits from stuffing it.

The long curve: inflation goes to zero, fees do not. Three scenarios are worth separating. If usage stays flat, fees remain about 1.5% of miner revenue indefinitely, and their dollar value tracks only the price: $3,848 of fees against $258,122 of total miner revenue a day at $588.61. If usage grows sevenfold, blocks fill and the four tiers become a real queue, with fees rising until demand is rationed. If fees fell to zero tomorrow, miners would lose 1.5% of revenue - painful to a marginal miner, but not a security event, because the tail subsidy is the budget. What fees actually buy Monero today is spam resistance, not security; treating them as the future security budget gets the arithmetic backwards. (how Monero fees work)

What this means when you swap. At 10:04 UTC on 26 October our quote endpoint priced 100 USDT-TRC20 at 0.14906925 XMR (670.83 USDT per XMR), 500 at 611.82, 1,000 at 604.43 and 5,000 at 599.98; 1 XMR bought 571.71 USDT. The gap between the 100 and the 5,000 order is about 10.5 USDT of fixed overhead per order - roughly 400 times the 2.6-cent Monero network fee for a two-in, two-out spend. So the thing worth optimising is order size and route, not sat/vB: paying four times the base XMR fee to move a deposit faster changes a 2.6-cent line item into a 10.5-cent one while blocks sit at 10% capacity, and the confirmation count that actually gates your payout is a block-count rule, not a queue position. (XMR to USDT exit)

Five things people get wrong. One: the 0.6 XMR is not paid to holders, it is paid to miners, and it is the largest single line in their revenue. Two: there is no halving and no hard cap; 2^64 is a field width. Three: a higher fee does not speed up XMR confirmations when blocks are a tenth full - it only matters when the block is contested. Four: fees are not tiny because nobody uses Monero, they are tiny because 600 kB blocks are rarely full; 26,936 transactions a day is real usage, it is just nowhere near the ceiling. Five: the 1.49% is not a rounding error to be waved away - it is the number that tells you which mechanism is load-bearing. (how Monero fees work)

The honest limits. This is one day, one node and one price snapshot. Block weights move with exchange batching, so a day with heavy consolidation looks nothing like a quiet Sunday. Our node is a restricted RPC endpoint: it serves headers and full blocks but refuses `get_transactions`, so block-level fee totals are exact (coinbase minus the base reward, with the penalty factor applied for the 59 heavy blocks) while per-transaction figures are tier times size, not decoded per transaction. The averages are therefore trustworthy in aggregate and approximate per transaction. Prices are from CoinGecko at 10:00 UTC and from our own quote endpoint at 10:04 UTC; live quotes move, and the page is the authority. (how Monero fees work)