pikochain

At 12:51 p.m. today, monitoring caught a 2v2 fork at height 909460: s1/s2 had head 0xa60fb1b4ae6b, while s3/s4 were on the other side (s4 had already sealed through 909461). The network went about 13–14 minutes without a new block.
According to our own recovery playbook, the next steps should be miner_stop, roll back to just before the fork point with debug_setHead, move the scheduled in-turn sealer to the majority chain to continue sealing, and use cumulative difficulty (TD) to overtake the other side and force a network-wide reorg. Over the past month and a half, we’ve used this playbook to fix things ourselves several times. The most nail-biting case was a permanent deadlock in which the TD of two forks was exactly tied, and nodes would never automatically reorg.