The OCEAN BIP-110 Incident: What a Fork-Chain Mixup Teaches Miners About Pool Choice

Short answer: in early August 2026, some miners connected to the OCEAN pool discovered that their hashrate had been mining blocks on the BIP-110 soft-fork chain for roughly 18 hours, despite never agreeing to signal for that soft fork. OCEAN acknowledged the problem publicly. The root cause traced back to the pool's default Stratum template, which signaled in favor of BIP-110, and some miners who had switched to alternate templates without that signal still ended up tied to the fork chain anyway. The story raises a question that goes well beyond one pool: how much control does a miner actually have over what their hashrate signals for, and what should you check before connecting to a pool so you do not end up in a similar spot.

POOL BTC is covering this case not to pass judgment on a specific pool, but to pull a practical lesson out of it for anyone deciding where to point their hashrate. What follows sticks to what OCEAN itself and independent outlets have confirmed, without speculating on causes or assigning blame.

What Happened: The Timeline

The BIP-110 soft fork entered its mandatory signaling window at block 961,632. At that point, it had support from roughly 2.6% of network hashrate against a required threshold of 55%. That gap was enough to rule out activation from the start, but the signaling mechanism itself still produced a separate fork chain: blocks that failed to carry the required BIP-110 signal ended up on one branch, everything else on another.

The fork chain managed to produce just two blocks, 961,632 and 961,633, before it stalled. The main chain, meanwhile, pulled more than 200 blocks ahead, meaning the overwhelming majority of the network kept operating as if the fork chain never happened.

The second fork block, 961,634, was mined by the Simple Mining group through Ocean's DATUM protocol. The notable detail here is that Simple Mining mined it without signaling for BIP-110, even though Ocean's pool defaulted to signaling in favor of the soft fork. CoinDesk confirmed this: Bitcoin Miner Rejects BIP-110 Despite Mining Through a Pool That Supported It.

The real story sits elsewhere, though. OCEAN acknowledged that for about 18 hours, some miners who had chosen non-BIP-110 Stratum templates, technically opting out of signaling for the fork, still ended up mining blocks on the fork chain without their consent. According to BeInCrypto, the community subsequently demanded that pool leadership be fired, and Adam Back publicly called the incident unacceptable. The Roughnecks group, which mined both fork-chain blocks, withdrew its support for the fork on August 9, after which OCEAN's hashrate dropped sharply. Source: Bitcoin Miners Demand Ocean Leadership Firing Over BIP-110.

Why This Was Technically Possible at All

The problem is not that multiple Stratum templates existed side by side. It is where a miner's hashrate physically ends up in the moment a pool or protocol switches or routes jobs. A miner only sees the template handed to them at that instant, and usually has no straightforward, real-time way to verify which chain a found block will actually count toward if the pool's internal routing behaves differently from what was expected.

In OCEAN's case, the situation was complicated by the fact that the pool offered miners a choice: signal for BIP-110 through the default template, or switch to an alternate Stratum template without that signal. The existence of that choice was supposed to protect dissenting miners from participating in the fork. By the pool's own admission, it did not protect everyone in practice, some hashrate that had nominally opted into the non-BIP-110 path still ended up on the fork chain for roughly 18 hours.

That points to a broader lesson that does not depend on the specifics of this one incident. Having a choice available in a pool's interface is not the same as a guarantee that the choice is enforced at every layer of traffic routing. The gap between "the pool offers a choice" and "the pool technically guarantees traffic isolation" can be invisible from the outside until something breaks.

The Role DATUM Played Here

One detail worth dwelling on is that block 961,634 on the fork chain was mined by the Simple Mining team through Ocean's DATUM protocol, without a BIP-110 signal, even though the pool defaulted to signaling in favor of it. That means miners using DATUM had the technical ability to configure their own block template and signaling independently of the pool's default policy.

DATUM shares some of the spirit behind the idea of decentralized block building that POOL BTC covered in depth in its piece on Stratum V2 and pool decentralization: the more control over block content and signaling stays with the miner instead of being fully delegated to the pool, the less a miner has to depend on the pool's default settings in contentious situations like a soft-fork activation.

Even that level of control did not fully prevent the problem, though. The 18-hour episode of dissenting miners getting tied to the fork chain happened at the same time that part of the community did, in principle, have the technical means to opt out. A more advanced protocol lowers the risk here, it does not eliminate it entirely if traffic routing inside the pool is not fully transparent.

What This Means for Choosing a Pool

The OCEAN and BIP-110 story is not a reason to conclude a specific pool acted in bad faith. It is a reason to build a list of questions worth asking any pool before pointing hashrate at it, especially during contentious protocol updates like a soft-fork activation.

Start by finding out which Stratum templates are available and how they differ by default, since if a pool offers several connection options, it helps to know in advance what signaling is baked into the default template and what needs to change in your configuration to get a different one. It is also worth asking whether the pool guarantees technical isolation between miners running different settings, because a choice existing in the interface is only half the story, the traffic for miners on different templates needs to actually be routed separately at the infrastructure level. Checking whether the pool supports protocols like DATUM or Stratum V2 with Job Declaration matters too, since the more control a miner can exercise over block content and signaling, the less they depend on decisions the pool made by default.

It also pays to look at how a pool communicates about contentious protocol updates ahead of time. A public, early statement about a pool's position on a specific soft fork, and how it will affect different categories of miners, cuts down on the odds of surprises at activation time. And finally, how a pool responds after an incident says a lot: acknowledging the problem, explaining the cause publicly, and shipping a technical fix all signal a pool willing to be accountable to its community, far more than silence or vague statements would.

A similar set of criteria is worth keeping in mind when evaluating payout schemes too, a topic POOL BTC covered in the complete reference on mining pool payout schemes from PPS to TIDES: the more transparently a pool explains its own mechanics, the fewer surprises a miner runs into down the line.

What Miners Can Do Right Now

If protocol updates and traffic routing are not an abstract concern for you but something worth acting on, a few things are worth checking.

Look at a pool's current Stratum templates and signaling settings before connecting, especially during periods of active soft-fork discussion in the community. Favor pools that explain their position on contentious protocol changes publicly and ahead of time, rather than pools you only learn about after an incident. Treat protocols that give miners more control, such as DATUM or Stratum V2 with Job Declaration, as a way to reduce dependence on a pool's default settings. And keep an eye on reputational signals from the community, public demands from miners or comments from well-known figures in the space often surface faster than a pool's own postmortem.

If you split hashrate across several pools, the OCEAN incident is one more reason to compare their approach to traffic routing transparency, not just their fees. POOL BTC's pool comparison section is a convenient place to check pools side by side on the parameters that matter. Anyone trying to estimate how switching pools or a pool's policy might affect earnings can run the numbers through the mining profitability calculator, and anyone withdrawing rewards to a card may find the crypto cards section useful as well.

FAQ

Does this incident mean OCEAN acted in bad faith?

No, the available sources make no such claim. OCEAN publicly acknowledged the problem, and the community, along with figures like Adam Back, called the incident unacceptable, but that speaks to the fallout, not to proven intent. POOL BTC is only reporting confirmed facts here and is not drawing conclusions about causes beyond what the sources themselves state.

What ultimately happened to the BIP-110 fork chain?

The fork chain produced only two blocks, 961,632 and 961,633, before stalling, while the main chain pulled more than 200 blocks ahead. With support from only about 2.6% of hashrate against a required 55% threshold, the fork never had a real path to activation.

How can I tell my hashrate will not end up in a similar situation on another pool?

There is no single universal test, but checking a pool's available Stratum templates, asking support directly about technical traffic isolation, and favoring protocols that give miners more control, such as DATUM or Stratum V2, all reduce the odds of running into something like this.

Disclaimer

This article is informational and based on reporting from CoinDesk and BeInCrypto as of August 10, 2026. POOL BTC is an independent site for comparing pools, calculators, and services and is not affiliated with the OCEAN pool. The situation surrounding this incident may still evolve, so check OCEAN's current official statements and independent sources before making any decisions.