Why do pools fork their own blocks?

[Cricktor]

Recently I observed something strange on https://fork.observer. There are currently a few occurances visible there when a mining pool has forked its own blocks:


My own node didn't see above fork, so can't provide any further details.


Also this fork wasn't seen by my own node.


Only this last fork was also observed by my own node. Here's the portion from the debug.log:

Code:

2025-09-01T15:52:16Z Saw new header hash=00000000000000000001f9d2891b2580a1ba5316948651b7e53ec024d159e4d6 height=912721
2025-09-01T15:52:16Z UpdateTip: new best=00000000000000000001f9d2891b2580a1ba5316948651b7e53ec024d159e4d6 height=912721 version=0x2d084000 log2_work=95.800758 tx=1235467945 date='2025-09-01T15:51:57Z' progress=1.000000 cache=166.6MiB(1048788txo)
...
2025-09-01T16:20:48Z Saw new header hash=0000000000000000000005d69e1b45c5fc045a7ef36281054690125aa4e1eafe height=912722
2025-09-01T16:20:48Z Saw new cmpctblock header hash=0000000000000000000005d69e1b45c5fc045a7ef36281054690125aa4e1eafe peer=4079
2025-09-01T16:20:48Z UpdateTip: new best=0000000000000000000005d69e1b45c5fc045a7ef36281054690125aa4e1eafe height=912722 version=0x25448000 log2_work=95.800770 tx=1235471810 date='2025-09-01T16:20:15Z' progress=1.000000 cache=166.8MiB(1071977txo)
2025-09-01T16:20:49Z Saw new header hash=00000000000000000002265cf3ec81a70bc15dbdf31e36d0d2c21689e9555dc0 height=912722
2025-09-01T16:22:00Z Saw new header hash=0000000000000000000106a89e0f1ed365dc6c89fd5800cff5673c252997c546 height=912723
2025-09-01T16:22:08Z UpdateTip: new best=00000000000000000001f9d2891b2580a1ba5316948651b7e53ec024d159e4d6 height=912721 version=0x2d084000 log2_work=95.800758 tx=1235467945 date='2025-09-01T15:51:57Z' progress=0.999993 cache=166.6MiB(1060974txo)
2025-09-01T16:22:08Z UpdateTip: new best=00000000000000000002265cf3ec81a70bc15dbdf31e36d0d2c21689e9555dc0 height=912722 version=0x2001a000 log2_work=95.800770 tx=1235471809 date='2025-09-01T16:20:15Z' progress=1.000000 cache=166.8MiB(1072217txo)
2025-09-01T16:22:08Z UpdateTip: new best=0000000000000000000106a89e0f1ed365dc6c89fd5800cff5673c252997c546 height=912723 version=0x2c4c8000 log2_work=95.800782 tx=1235476515 date='2025-09-01T16:21:42Z' progress=1.000000 cache=167.0MiB(1079133txo)

The two new header announcements for block 912722 came just one second apart to my node. And I was a bit surprised to see that there was a second UpdateTip event for block 912721, quite some minutes past the first one.

I'm still wondering why this happens to a pool. So far I could only observe this for Foundry USA and ViaBTC. Any explanations or ideas for this?

My naive thinking is, once a pool finds a block, they are the first to know to immediately start mining on top of their own last block. If they get lucky to find another block quickly, they'd have two blocks potentially pocketed. It doesn't make sense to me to fork their own block.

As I'm no mining pool "mechanics" expert, I'd like to know why this happens and why pools don't prevent this to occur.

[ABCbits]

I'm still wondering why this happens to a pool. So far I could only observe this for Foundry USA and ViaBTC. Any explanations or ideas for this?

My speculation is those pool run multiple servers either for redundancy or allowing miner on different region to have lower latency/higher bandwidth. Node on those server immediately broadcast mined block, without checking whether other of their server have also mined block with same height first.

[Knight Hider]

When 2 users of a mining pool find the same block number at the same time, one has to fork.
The second block 912721 minutes later was not a new block, it was the new best known to your node at that moment after block 912723 removed your block 912722 as best block.

[BattleDog]

Short answer: it isn't intentional and there's nothing "mystical" going on – you're seeing race conditions inside a very large pool.

A pool is not one machine. Foundry/ViaBTC have many stratum servers, proxies and miners spread across the world. When one of their miners finds a block at height H, the pool has to build a new template whose prev-hash is that block and push a clean job to all connected miners so they stop working on the old tip.

Neither step is instantaneous. It takes tens–hundreds of milliseconds to build/distribute a new job, and some miners/proxies are a few hundred ms or even seconds away over the network. During that window a different miner from the same pool can still be hashing on the old job and may find another block. Now the pool has two blocks at the same height. Whichever propagates better wins; the other becomes an orphan. From the outside this looks like "the pool forked itself".

Why you didn't always see it on your node? Probably because very short-lived blocks get eclipsed before they reach all peers. You only see the block that reached you first; fork.observer aggregates data from many nodes and can show blocks that your node never received. In your log you have two UpdateTip lines for the same height with different hashes – that's exactly a one-block reorg caused by two competing blocks (both tagged to the same pool).

Pools can't really totally prevent this, they can only reduce the probability by doing things like:
Push "clean_jobs=true" immediately after a new tip, keep very fast block propagation (FIBRE, compact blocks, good peering), lower template refresh latency and avoid slow stratum/proxy setups, Stratum V2 (job negotiation) helps, but still can't make propagation instantaneous.

As long as pools are globally distributed and block propagation isn't instantaneous, occasional self-forks are unavoidable. Your observations for Foundry/ViaBTC are consistent with that.

[Cricktor]

...

Some sort of decentralization (redundancy and/or regional) was also something I had in mind. Sounds plausible to me.

...

I know that block 912721 was in both UpdateTip events the same, clearly visible by the same hash. I was just surprised why it would need a second UpdateTip when this block 912721 wasn't realy affected by the fork of block 912722. It was block 912723 which decided what branch of the former tip of 912722 should be followed as the "true" blockchain (most accumulated hash work).

...

Thanks for the more in-depth explanations. I had only vague and more incomplete thoughts what probably was going on. With the immense hash power of those pools, many many devices are crunching hashes, timely coordination becomes a real problem and the competitive mining space doesn't make it easier.

I assume it's not trivial to manage such a large amount of mining gear and participating miners. As you say, I can follow that occasional race conditions happen. Trying to cope and avoid them completely likely has more or other disadvantages than letting them happen.


I didn't expect that my node see most or a lot of the forks. It totally depends on my node's peers and I didn't specifically tune it to be any optimized for such a task. RPC getchaintips gives me a list of branch forks where block 723102 is the first in my list and remarkable entries are the invalid blocks 783426, 784121 and 809478.

[Knight Hider]

...

I know that block 912721 was in both UpdateTip events the same, clearly visible by the same hash. I was just surprised why it would need a second UpdateTip when this block 912721 wasn't realy affected by the fork of block 912722. It was block 912723 which decided what branch of the former tip of 912722 should be followed as the "true" blockchain (most accumulated hash work).

It updates one block at a time. To go from old 912722 to new 912723 it has to count down making 912721 the new best for only a fraction of a second before continuing with the new 912722 and 912723.