Decentralized Mining Pools: How Ocean and DEMAND Challenge Pool Centralization

Bitcoin's security model assumes that no single entity controls a majority of hashrate. In practice, a handful of mining pools dominate block production: Foundry USA and AntPool together account for roughly 50% of all blocks mined, and the top six pools produce over 80%. These pools decide which transactions go into block templates, creating a chokepoint where censorship and regulatory pressure can compromise Bitcoin's core promise of permissionless transactions.

Two projects are challenging this status quo with fundamentally different architectures. Ocean, co-founded by Bitcoin Core developer Luke Dashjr and backed by Jack Dorsey, uses its custom DATUM protocol to let miners build their own blocks. DEMAND Pool (DMND), the first pool built natively on Stratum V2, uses the protocol's Job Declaration feature to achieve a similar goal. Both represent a shift in how mining pools operate: from centralized block constructors to infrastructure that serves miners who construct their own blocks.

Why Mining Pool Centralization Matters

Under the traditional pool model, miners contribute hashrate and the pool operator handles everything else: running a Bitcoin node, selecting transactions from the mempool, constructing the block template, and distributing work to miners via the Stratum protocol. Miners receive pre-built work units and have no say in what transactions their hashpower confirms.

This delegation of block construction creates several risks. A pool under regulatory pressure could exclude transactions from sanctioned addresses or filter specific protocol activity. If that pool controls 30% of hashrate, affected transactions face significant confirmation delays. The threat is not theoretical: in late 2024 and early 2025, monitoring by developer 0xB10C detected fifteen OFAC-sanctioned transactions missing from F2Pool blocks, suggesting the pool had resumed filtering sanctioned addresses.

Current Hashrate Distribution

The concentration of hashrate among a few operators illustrates the scale of the problem. As of mid-2026, the distribution of mining power looks like this:

Four pools control roughly 71% of global hashrate. In January 2025, a severe winter storm in the United States caused Foundry USA's hashrate to drop by approximately 60% in a matter of hours, illustrating the fragility of geographic and operator concentration. When a single pool losing power can remove roughly 200 EH/s from the network overnight, the centralization risk is not abstract.

The block template bottleneck: Even if a pool has thousands of independent miners contributing hashrate, a single operator still decides which transactions appear in every block that pool mines. Decentralized mining pool designs aim to break this bottleneck by pushing block template construction back to individual miners.

How Ocean Decentralizes Block Construction

Ocean launched in late 2023, co-founded by Luke Dashjr (a longtime Bitcoin Core contributor) and funded by a seed round led by Jack Dorsey. The pool's design philosophy centers on two principles: miners should control what goes into their blocks, and payouts should be non-custodial.

DATUM: Decentralized Alternative Templates for Universal Mining

Ocean's approach to decentralized block construction is the DATUM protocol, launched in September 2024. DATUM stands for Decentralized Alternative Templates for Universal Mining. Rather than adopting Stratum V2, Ocean built a purpose-specific protocol that acts as a bridge between three components: a miner's own Bitcoin full node, their ASIC hardware, and the Ocean pool server.

The DATUM Gateway is a lightweight C application that runs alongside a Bitcoin node. It calls getblocktemplate on the local node to retrieve a fresh template, generates work units for connected ASICs using Stratum v1 with version rolling (ASICBoost), and communicates with Ocean's DATUM Prime server over an encrypted link. The pool validates the coinbase structure but cannot dictate which transactions the miner includes.

This design means the DATUM protocol has no mechanism for the pool to provide block template data. The information flow is intentionally one-directional: miners declare templates, the pool accepts valid ones. Ocean also offers a fallback mode where the pool provides templates for miners who do not run their own nodes, but DATUM miners pay lower fees (1% vs. the standard 2%) as an incentive to run the decentralized configuration.

TIDES: Non-Custodial Payout System

Ocean's payout model is called TIDES: Transparent Index of Distinct Extended Shares. Unlike traditional pools that accumulate miner balances in a pool-controlled wallet and pay out periodically, TIDES writes miner payouts directly into the coinbase transaction of each block Ocean finds.

TIDES determines each miner's share by tracking contributions in a rolling window equivalent to the last eight blocks worth of network difficulty. It calculates the exact pro-rata portion of each miner's contributed hashrate, including both the block subsidy and transaction fees. Because payouts are embedded in the coinbase transaction itself, Ocean never takes custody of miner funds: the protocol pays miners directly.

Non-custodial by design: Most mining pools operate as custodians, holding miner rewards in pool-controlled wallets until a payout threshold is met. Ocean's TIDES model eliminates this custody requirement entirely. Miners receive their sats from the Bitcoin protocol itself, reducing counterparty risk.

How DEMAND Pool Uses Stratum V2

DEMAND Pool (DMND) takes a different path to the same destination. Rather than building a custom protocol, DMND is the first mining pool built natively on Stratum V2, the open-source successor to the original Stratum mining protocol. DMND launched publicly in November 2025 and on June 25, 2026, mined block 955,318: the first known Bitcoin block produced using Stratum V2's Job Declaration feature, where miner GoMining selected its own transactions and built its own template.

Job Declaration: The Core Mechanism

Stratum V2's Job Declaration Protocol is the specific sub-protocol that enables miner-constructed templates. A miner (or mining farm) runs their own Bitcoin node, constructs a custom block template from their local mempool, and declares that template to the pool. The pool validates that the coinbase transaction structure is correct for proper payout accounting but cannot reject a valid template based on which transactions it includes.

The protocol replaces Stratum V1's JSON-RPC messages with a compact binary format, reducing bandwidth by approximately 70%. Job delivery targets latency under 2.5 milliseconds, compared to roughly 228 milliseconds under V1. DMND also implements end-to-end encryption between miners and the pool server, preventing hashrate hijacking attacks where a man-in-the-middle redirects mining work to a different pool.

SLICE: Rewarding Template Quality

DMND uses a payout system called SLICE, which splits each block reward into two components. The block subsidy (currently 3.125 BTC) is distributed via classic PPLNS based on hashrate contribution alone. Transaction fees, however, are distributed via PPLNS weighted by Job Declaration scoring: miners who build more valuable block templates (selecting higher-fee transactions) earn a larger share of the fee revenue.

This creates an economic incentive for miners to run their own nodes and optimize their templates. SLICE also divides the lookback window into short time-boxed slices, removing the unfairness of comparing shares submitted hours apart. The result is a payout scheme with lower variance than pure PPLNS, lower cost than FPPS (since pools do not need to subsidize variance), and full compatibility with miner-built block templates.

DATUM vs. Stratum V2: Two Approaches Compared

Ocean and DMND solve the same problem with different engineering choices. Understanding the tradeoffs helps miners evaluate which approach fits their operation.

The most significant architectural difference is portability. DATUM is Ocean-specific: if a miner leaves Ocean, their DATUM setup has no use elsewhere. Stratum V2 is an open standard supported by a growing number of pools. As of mid-2026, three pools run V2 natively (Braiins Pool, DMND, and ckpool), and seven major pools representing approximately 75% of global hashrate have joined the Stratum V2 Working Group. The SRI (Stratum Reference Implementation) working group projects that by the end of 2026, V2 will be the default protocol for new ASIC firmware shipments.

Payout Models: FPPS, PPLNS, TIDES, and SLICE

The economics of mining pool participation depend heavily on the payout model. Traditional pools use one of two dominant approaches, while Ocean and DMND each introduce alternatives. For a deeper breakdown, see our full comparison of mining pool payout methods.

FPPS dominates among large pools because it offers the most predictable daily revenue: miners get paid based on estimated block subsidy plus an average transaction fee component, regardless of whether the pool actually finds a block. The pool absorbs all variance risk, which it finances through higher fees (typically 2-4%) and by keeping the upside when actual fees exceed the estimated average.

TIDES and SLICE both distribute actual block revenue rather than estimates, which means miners participate in fee upside during high-fee periods but also bear the variance of pool luck. The tradeoff is transparency and, in Ocean's case, the elimination of custody risk entirely.

Censorship Resistance and Transaction Filtering

The strongest argument for decentralized block template construction is censorship resistance. When a pool operator builds every template, they become a single point where external pressure can be applied. A government agency, a compliance department, or even a pool's own policy can decide to exclude certain transactions.

This concern is grounded in precedent. Marathon Digital (now MARA) announced in 2021 that it would mine only "OFAC-compliant" blocks, filtering transactions from sanctioned addresses. The company reversed course after community backlash, but the episode demonstrated that pool-level censorship is technically trivial when the pool controls the template.

When miners construct their own templates using DATUM or Stratum V2's Job Declaration, the pool cannot filter transactions because the pool never selects them. Each miner independently queries their own node's mempool and includes whatever transactions they choose. A pool might still refuse to accept a template containing specific transactions, but the Stratum V2 specification explicitly prohibits rejecting valid templates based on transaction content: pools can only validate the coinbase structure.

MEV Resistance on Bitcoin

While maximal extractable value (MEV) is primarily an Ethereum concern, Bitcoin is not entirely immune. The growth of Ordinals, BRC-20 tokens, and Runes has introduced transaction ordering incentives: sniping high-value inscription mints or front-running token trades. When a pool operator orders transactions, they can extract this value at miners' expense.

Decentralized template construction distributes ordering authority across thousands of independent miners, making coordinated extraction far more difficult. Each miner builds their own template from their own mempool view, and the winning block reflects one miner's transaction selection rather than a centralized operator's optimization.

Tradeoffs and Challenges

Operational Complexity

Running a full node alongside mining hardware is not trivial. Miners need to maintain a synced Bitcoin node, manage disk space for the blockchain, and ensure reliable network connectivity. For large operations with dedicated infrastructure teams, this is straightforward. For smaller miners and home operations, the additional complexity may outweigh the decentralization benefits.

• A synced Bitcoin Core node requires approximately 700 GB of disk space (pruned mode reduces this significantly)
• The DATUM Gateway is lightweight (written in C) but adds another service to monitor
• Stratum V2 requires firmware updates on ASIC hardware, which not all manufacturers support yet

Pool Size and Variance

Ocean currently operates with roughly 13 EH/s, representing about 2% of network hashrate. Smaller pools find blocks less frequently, which means higher payout variance for miners. A pool finding one block per day on average will have days with zero blocks and days with several: miners with thin margins may prefer the predictability of an FPPS pool like Foundry even if it means surrendering template control.

DMND faces the same cold-start challenge that any new pool confronts: attracting enough hashrate to find blocks consistently. The SLICE payout model's time-boxed slices mitigate some variance, but the fundamental constraint of pool size remains.

Firmware and Hardware Support

Stratum V2 adoption depends on ASIC manufacturers shipping compatible firmware. As of mid-2026, Bitmain and MicroBT have announced V2 support in newer models, but the majority of deployed ASICs still run V1 firmware. Ocean sidesteps this problem by using Stratum V1 as the miner-facing protocol while adding DATUM as the pool-facing layer: any V1-compatible ASIC works with Ocean.

Adoption trajectory: The Stratum V2 Working Group projects that V2 will become the default protocol for new ASIC firmware shipments by the end of 2026. If this timeline holds, the firmware compatibility barrier will diminish rapidly as older hardware is retired and replaced.

Why Decentralized Mining Matters for Layer 2 Protocols

Bitcoin's Layer 2 protocols inherit their security guarantees from the base layer. If a Layer 2 user needs to settle on-chain (closing a Lightning channel, broadcasting a unilateral exit from Spark, or publishing a fraud proof for a rollup), that transaction must be included in a Bitcoin block. If the dominant mining pools are filtering transactions, a Layer 2 user's ability to enforce their rights on the base layer could be compromised.

Decentralized mining pools reduce this risk by ensuring that no single pool operator can unilaterally decide which transactions get confirmed. When thousands of miners independently construct block templates, a transaction rejected by one miner will be included by another. This strengthens the censorship resistance guarantees that every Layer 2 protocol depends on: the assurance that valid Bitcoin transactions will eventually be mined, regardless of their content.

For developers building on Bitcoin's Layer 2 ecosystem, the health of mining decentralization directly affects the security assumptions underlying their applications. The Spark documentation covers how unilateral exits work and why base-layer censorship resistance is essential to the protocol's security model. For further reading on the mining centralization landscape, see our research on mining centralization risks and the Stratum V2 protocol.

Looking Ahead

The trajectory of decentralized mining pool adoption will be shaped by three factors: firmware support, economic incentives, and regulatory pressure. As Stratum V2 firmware becomes standard in new ASICs, the barrier to miner-constructed templates drops. As transaction fees become a larger component of block rewards (particularly after future halvings), SLICE-style models that reward template quality will become more attractive. And as regulatory scrutiny of mining pools intensifies, miners who want to avoid compliance entanglements at the pool level will have stronger motivation to control their own templates.

Ocean and DEMAND represent two viable approaches to the same structural problem. Ocean offers a working solution today with minimal hardware requirements and non-custodial payouts. DEMAND bets on an open standard with broader ecosystem support and an economic model that rewards template optimization. Both demonstrate that the concentration of block construction authority in a handful of pool operators is a design choice, not an inevitability: and that miners have the tools to choose differently.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.