The Two Paychecks Miners Actually Receive
It's the morning after a halving. You open Tariq's accounting software over his shoulder. The subsidy line just got cut in half. Overnight, no warning, exactly as scheduled. That part everybody knows. What the headlines skip is that the second line, the one labeled transaction fees, didn't move at all. Not a satoshi.
That's the whole story, really. But the mechanics matter more than the conclusion, so let's go.
Every time a Bitcoin block is mined, the miner who finds it collects two completely separate things. First, the block subsidy: newly minted bitcoin, created from nothing, governed by the protocol's hard-coded schedule. Second, transaction fees: sats that users attached to their pending transactions, bidding for space in that block. These two revenue streams have different origins, different rules, and critically, different sensitivities to the halving. The subsidy is cut by 50% on a fixed schedule, roughly every 210,000 blocks, which works out to about four years at the ten-minute target. The fees are not touched by that schedule at all. They're determined entirely by the mempool.
What the Mempool Actually Controls
The mempool is the waiting room. Every unconfirmed transaction sits there until a miner picks it up. Users who want faster confirmation attach higher fees. Miners, rationally, sort by fee rate (satoshis per byte of block space) and grab the highest-paying transactions first. Block space is capped at roughly 4 million weight units per block, so when demand for that space is high, fees climb. When the network is quiet, fees collapse toward the floor.
Notice what's absent from that description: the halving.
The subsidy schedule and the fee market are parallel systems. One is a protocol clock; the other is a live auction. A halving doesn't change block size, doesn't change transaction demand, doesn't change user behavior in the mempool. Fee revenue on the day after a halving is a function of how busy the network is. Full stop.
Here's a worked example to make it concrete. Suppose a block contains 2,500 transactions averaging 40 sat/vbyte in fees, and the block is roughly 1.5 MB in virtual size. Total fee revenue for that block comes out to around 0.15 BTC, give or take. The subsidy in that same block might be 3.125 BTC, the figure after the fourth halving. Cut the subsidy in half at the next halving: fee revenue stays at roughly 0.15 BTC. The miner's total drops from about 3.275 BTC to about 1.275 BTC per block, but the fee contribution is inert. It didn't participate in the cut.
The Part Most Guides Skip
A lot of writing on this subject goes wrong in the same way: it conflates the immediate effect of the halving with longer-term fee dynamics, then treats the conflation as settled fact. This is, to put it plainly, sloppy thinking dressed up as analysis.
Yes, in the long run, the halving matters to fee revenue indirectly. If a halving squeezes miner margins enough to push some operations offline, hashrate drops, difficulty adjusts downward over roughly two weeks of blocks, and the network finds a new equilibrium. Real mechanism. But it operates on a two-week lag at minimum, through the difficulty adjustment algorithm, and even then it affects miner profitability rather than fee revenue per block directly.
The other indirect path: if higher bitcoin prices follow a halving, more users might transact, swelling the mempool, pushing fees up. That's a market effect, not a protocol effect. Speculation dressed in mechanism clothing. Treat it as such.
The direct, immediate, mechanical truth is simple. Halving day is fee-neutral.
Two Miners, One Morning
Back to Tariq. He runs an efficient operation in a low-cost energy region. His neighbor Priya runs older hardware with higher electricity costs. On halving day, both see their subsidy income halved. Neither sees their fee income change. Tariq weathers it, his margins thinner but still positive. Priya's operation tips into unprofitability. She shuts down some rigs.
Now the network's hashrate is slightly lower. Over the next 2,016 blocks, the difficulty adjustment window, the protocol notices blocks are arriving a little faster than ten minutes on average and adjusts difficulty downward. Tariq's remaining hardware finds blocks slightly more often. His share of fee revenue per unit of hashrate improves marginally. Fees per block, though? Still determined by the mempool. Still not touched by the halving clock.
This is why the distinction matters for anyone trying to model miner economics. The halving is a subsidy event, not a fee event. Keeping those two ideas tangled together is like confusing a landlord's mortgage payment schedule with his tenants' rent checks: related businesses, entirely separate ledgers.
Why This Will Matter More Over Time
Bitcoin's subsidy schedule has a terminal condition baked in. Around the year 2140, the last satoshi of subsidy will be minted. After that, every miner in the world earns nothing but fees. Satoshi Nakamoto described this transition explicitly in the original white paper. It isn't a design flaw to be patched; it's the intended endpoint.
The halving, then, is a slow dress rehearsal for a fee-only regime. Each cycle, the subsidy shrinks relative to total miner revenue. Each cycle, the fee share grows in proportional importance, even if the absolute fee figure doesn't move. At the fourth halving, on a busy day, fees might represent 5-10% of a block's total miner reward. That figure will keep climbing across future halvings, not because fees are rising, but because the subsidy denominator keeps shrinking.
The real question for Bitcoin's long-term security isn't what happens to fees on halving day. It's whether fee revenue can eventually grow large enough, in absolute terms, to sustain the hashrate the network needs. That question is genuinely open, and any analyst who claims certainty in either direction is selling something.
If you're modeling miner revenue, keep two separate columns. The halving writes to one of them. The mempool writes to the other. They have never shared a formula, and understanding that is the beginning of actually thinking clearly about Bitcoin's security budget.