One Block, Many Winners: How Tailstorm Decentralizes Mining Rewards on Nexa

By jQrgen (Jørgen S. Notland)

In Bitcoin-style mining, one miner wins each block and everyone else gets nothing for that round. If you are small, you can go a long time between payouts. So small miners join big pools, and big pools get bigger.

Tailstorm, the consensus upgrade coming to Nexa with Hard Fork 2, changes that maths. Every block is assembled from many smaller proofs of work, and the block reward is split across their miners. Here is how that works, what the research actually shows, and what is still open.

The problem: winner-takes-all is lumpy

On Nexa today, as on Bitcoin, a block needs one proof of work, and its finder takes the whole reward. Nexa targets one block every 2 minutes.

If you control 1% of the hash rate, you win about 1 block in 100 on average. That is roughly one payout every 200 minutes, with long dry spells in between. (This is simple arithmetic from the 2-minute target, not a measurement.)

Most miners don't want that variance, so they join pools. The Tailstorm paper puts it directly: unfair or inconsistent rewards encourage the formation of pools and centralisation. The wider research is blunt too: even small advantages for larger miners push a proof-of-work system toward centralisation.

What Tailstorm changes

Tailstorm comes from a peer-reviewed paper by Patrik Keller, Ben Glickenhaus, George Bissias and Gregory Griffith (AFT 2023). The core idea in plain language:

• One block becomes k small proofs of work. Miners find subblocks, each one much easier than a full block. Once there are k of them, they are tied together into a summary block.
• Subblocks don't race each other. Subblocks that build on the same summary don't conflict, so they can be found in parallel, and fewer are thrown away than in Bitcoin's one-winner race.
• Rewards go to subblock miners. In the paper, every subblock in a summary gets paid, not just one lucky winner.

On Nexa, in the current code, the summary block's coinbase (the transaction that pays the block reward) pays out the full reward, so nothing is burned. It is split across every subblock in the winning DAG, weighted by how well-connected each subblock is. In a clean, linear chain of subblocks, every subblock, and the summary block's own miner, gets an equal share. Late subblocks (uncles) are still paid in the next block, at slightly less than a well-linked subblock. Nodes enforce the split: a summary block whose coinbase doesn't match the DAG is rejected.

The number of subblocks per summary isn't final. The code uses k = 120 for mainnet and testnet, about one per second at 2-minute blocks. The stormtest test network is still set to 40 upstream, which is likely where the "about 40, every 3 seconds" in recent announcements comes from. Neither number is a final activation setting. Either way, a block reward that today goes to one miner would be split across dozens of miners.

Why smaller miners benefit, and why pools may matter less

1. Payouts become frequent instead of lumpy. The paper simulated one strong miner and one weak miner over many simulated days. Higher k gave more frequent rewards and lower day-to-day volatility.

To illustrate (my own arithmetic, idealised: no orphans, equal shares), take a miner with 1% of the hash rate. Here k is the number of pieces of work per block, including the summary, and the chance of winning at least one is 1 − 0.99^k:

Total expected income stays the same. What changes is how smooth it is.

2. Less unfairness from network delays. In Bitcoin, when two blocks are found at about the same time, one is orphaned, and the bigger miner is more likely to win that race. Tailstorm's analysis gives a lower upper bound on orphan rates than Bitcoin's at the same block interval. In simulation, the weak miner got closer to its fair share. The paper also shows a design benefit: block interval (for fairness) and subblock interval (for frequent payouts) can be tuned separately, instead of trading one against the other as Bitcoin must.

3. Withholding blocks pays less, in the paper's model. "Selfish mining" means a big miner hides blocks to gain an unfair share. In the paper's attack search, Tailstorm needed the largest share of hash rate before dishonest strategies paid off, compared with Bitcoin and a parallel-PoW protocol without Tailstorm's reward rule. That matters for decentralisation, because a protocol that rewards size invites consolidation.

One caveat: that result is for the paper's reward rule. Nexa splits the reward differently (see above), and nobody has yet analysed whether Nexa's rule resists withholding as well. It's an open research question.

What the research does not claim

I want to be precise here:

• The paper measures fairness (are rewards proportional to hash rate?), reward volatility, orphan rates and resistance to withholding attacks.
• It states that unfair or inconsistent reward allocation "encourages the formation of pools and centralization". But it does not model pools, pool fees, or miners' decisions to join or leave pools. "Smaller pools become more viable" is my reasoning from lower variance and better fairness. It is not a measured result in the paper.
• The authors themselves say Tailstorm reduces but cannot fully remove centralisation pressure, because economies of scale in energy and hardware affect every proof-of-work coin.
• Nexa's reward weighting is its own implementation of the idea. In the paper, the total paid shrinks when the subblock tree branches. Nexa's current code always pays the full reward and changes only how it is split. How that behaves under adversarial conditions deserves independent review.

Status

The Tailstorm code shipped in Nexa Full-Node 2.2.0.0 and is dormant until Hard Fork 2 activates in the next release. The roadmap targets the 2026 hard fork. The spec page lists 1 November 2026, while the released code still carries a placeholder date, so treat the date as provisional.

For developers

A network that pays many miners every block is the kind of base layer I want under payment apps: confirmations in seconds, and security that doesn't depend on a handful of pools. If you are building payments, point-of-sale, tokens or mining tooling (pool dashboards, payout trackers, gettailstorminfo monitors), start now:

• Build On Nexa: https://build.nexa.org
• Hard Fork 2 spec: https://spec.nexa.org/upgrades/hard-fork-2/
• Tailstorm implementation notes: https://gitlab.com/nexa/nexa/-/blob/dev/doc/tailstorm.md
• The paper: https://arxiv.org/abs/2306.12206

Building in Scandinavia? Reply or DM me.