DATUM Protocol: How OCEAN Lets Miners Choose Their Own Transactions

DATUM (Decentralized Alternative Templates for Universal Mining) is an open-source gateway protocol developed by OCEAN Pool that allows miners to construct their own Bitcoin block templates locally — meaning you, not the pool, choose which transactions your miner includes in every block it mines.

What is the DATUM protocol?

DATUM stands for Decentralized Alternative Templates for Universal Mining. It is a Bitcoin mining protocol created and open-sourced by OCEAN Pool, the mining pool founded in 2023 by the team behind Bitcoin Knots and built around a philosophy of transparent, miner-sovereign pool operation.

In conventional pool mining, the pool constructs the block template — a list of which transactions go into the next block — and pushes it to every connected miner. The miner has no say in transaction selection. This centralization of template construction has been a quiet but significant trust assumption for most of Bitcoin mining’s history.

DATUM removes that assumption. It introduces a lightweight software layer — the DATUM Gateway — that runs locally on your network alongside your own Bitcoin full node. Your node’s mempool policy determines the transaction list. OCEAN Pool provides only the coinbase payout structure and share-counting infrastructure. The creative and political act of choosing which transactions enter a block returns to the individual miner.

The DATUM Gateway is free, open-source software. The source code is maintained by OCEAN at github.com/OCEAN-xyz/datum_gateway. As of mid-2025, it remains in active beta development.

How DATUM differs from Stratum V2

DATUM and Stratum V2 (SV2) share the same goal — putting transaction selection in miners’ hands — but they take fundamentally different architectural paths to get there.

Feature	Stratum V1	Stratum V2	DATUM
Block template source	Pool always	Pool default; miner optional via Job Declaration sub-protocol	Miner’s local full node, always
Transaction selection	Pool only	Pool default; miner optional (JD required)	Miner always
ASIC firmware changes required?	No	Yes — firmware must speak SV2 binary frames	No — ASICs speak standard Stratum V1
Wire protocol	JSON over TCP	Binary frames, Noise_NX encryption	SV1 to ASICs; custom encrypted binary (libsodium) gateway↔pool
Bitcoin full node required?	No	No (unless JD active)	Yes — mandatory
Pool sees your transactions?	Yes	Optional (not with JD)	No — pool receives only merkle branches, never the transaction list
Block broadcast by	Pool	Pool	Your node broadcasts directly to the Bitcoin network

The key practical distinction: Stratum V2 is a full protocol rewrite that requires updated firmware on your ASICs to unlock its privacy and transaction-selection features. DATUM is a proxy overlay — your Antminer or Bitaxe still speaks ordinary Stratum V1 to the local DATUM Gateway, which handles all the heavy lifting. No firmware update required for most hardware.

Both approaches are legitimate paths toward the same goal. They were built by different teams standing on the shared foundation of Bitcoin’s open development culture. DATUM is simpler to deploy today for miners with V1 hardware; Stratum V2 may become the broader long-term standard as firmware adoption grows.

How DATUM works: the technical architecture

DATUM operates across three components, two of which you control locally. (Source: Stratum Protocol Bible, Section 6 — DATUM Protocol (OCEAN), D-Central Mining Knowledge Base.)

The three DATUM components

• Your Bitcoin full node (local). Provides block templates via the getblocktemplate RPC. Your node’s mempool and policy settings — which transactions it accepts and prioritizes — determine what goes in the block. The node must be configured with blockmaxsize=3985000 and blockmaxweight=3985000 to reserve approximately 15,000 weight units for the pool’s reward distribution outputs.
• DATUM Gateway (local, open-source). The bridge layer. It pulls block templates from your node, constructs the coinbase transaction (incorporating the pool-provided payout outputs), assembles the merkle tree, and serves work to your ASICs over standard Stratum V1 — including version rolling for ASICBoost support. It also maintains an encrypted connection to DATUM Prime using a custom binary protocol secured with libsodium (NaCl-based cryptography).
• DATUM Prime (OCEAN’s pool server). Provides the coinbase output structure (the payout split so the pool can distribute rewards fairly among participants), a coinbase tag for pool identification, and share-counting infrastructure. Critically, DATUM Prime does not construct block templates or provide a transaction list — it never learns which transactions you chose.

The template construction flow

1. A new Bitcoin block arrives (or your node’s mempool changes), triggering a blocknotify signal to your DATUM Gateway.
2. The gateway calls getblocktemplate on your local node, receiving the prev_hash, selected transactions, coinbase value, difficulty target, and related fields.
3. The gateway fetches the required coinbase outputs from DATUM Prime — the pool’s reward-distribution addresses, its coinbase tag, and a unique pool identifier.
4. The gateway builds the complete coinbase transaction locally: pool outputs, witness commitment OP_RETURN, block height per BIP 34, pool coinbase tag, and a reserved extranonce slot.
5. The gateway computes the full merkle tree from all transactions and distributes work to your ASICs via standard mining.notify messages.
6. When your hardware finds a valid share, the gateway validates it locally against your node’s template, then forwards only the merkle branches (not the transaction data) to DATUM Prime for share accounting.
7. When your miner finds a block: your node broadcasts the solved block directly to the Bitcoin network. The pool cannot broadcast on your behalf — this is by design. You are a first-class participant in block propagation, not a passive subcontractor.

The gateway’s local web dashboard is available at http://[gateway-ip]:7152 for monitoring share rates and template status.

Setup guide: connecting your miner to a DATUM gateway

Running DATUM requires two pieces of local infrastructure: a Bitcoin full node and the DATUM Gateway software. This makes it a meaningful commitment — suitable for serious home miners and anyone operating a small pool vs. solo setup who wants to reclaim template sovereignty without leaving pool-smoothed rewards entirely.

Requirements

• A machine running Bitcoin Core (or a compatible full node with getblocktemplate support) — synchronized and with adequate storage (~700 GB+ as of mid-2025, growing)
• A separate or same machine to run the DATUM Gateway binary (Linux; a Raspberry Pi 4 or higher, NUC, or any always-on box is sufficient)
• Your existing Antminer, WhatsMiner, Bitaxe, or other Stratum V1-compatible ASIC hardware — no firmware changes required

Bitcoin node configuration (bitcoin.conf)

blockmaxsize=3985000
blockmaxweight=3985000
server=1
rpcuser=yourusername
rpcpassword=yourpassword

DATUM Gateway installation

Download the latest release from github.com/OCEAN-xyz/datum_gateway/releases. OCEAN also maintains a Start9 package (datum-gateway-startos) for miners running a Start9 sovereign server. Follow the official setup documentation at ocean.xyz/docs/datum-setup for the most current configuration options — the protocol is in active beta and endpoint details may be updated between releases.

Pointing your miner at the gateway

In your ASIC’s web interface, set the pool URL to:

stratum+tcp://[your-gateway-ip]:23334

Set the username to your Bitcoin address (optionally appended with a worker name: bc1q...youraddress.worker1). Rewards flow directly to the address you specify on OCEAN.

Verify your miner is submitting shares at ocean.xyz/stats/[your-bitcoin-address].

For Bitaxe miners: the Bitaxe speaks standard Stratum V1 and can connect to a local DATUM Gateway the same way as any other hardware. The gateway can run on a separate always-on machine (a Raspberry Pi, for instance) on your local network. See the open-source miners hub for related setup context.

Flag: always verify connection details and gateway version against the official OCEAN documentation at ocean.xyz/docs/datum-setup before configuring production hardware — this is beta software and configuration parameters may evolve.

Why transaction selection matters for Bitcoin sovereignty

When a pool selects transactions, it makes policy decisions that affect Bitcoin’s censorship resistance. Historically most pools have applied relatively permissive mempool policies. But the debate sharpened in 2023–2024 as OCEAN implemented an OP_RETURN size limit that filtered certain inscription-type transactions — a decision praised by Bitcoin minimalists and criticized by others as a form of censorship in its own right.

The point is not which policy is correct. The point is: who decides?

With DATUM, the answer is the miner running the node. If you run Bitcoin Core’s default policy, you get default mempool policy. If you run Bitcoin Knots with stricter filters, you get Knots policy. If you configure a custom mempool, you get your custom mempool. The pool coordinates reward distribution; it does not dictate your block’s contents.

This is the sovereignty thesis applied to mining infrastructure: the same principle that motivates running your own node for verifying payments motivates running your own node for validating — and selecting — blocks. D-Central has been building around this principle since 2016. Transaction selection is not a nuance; it is one of the last meaningful levers a participating miner has over Bitcoin’s consensus layer.

For a deeper look at how firmware choices affect who controls your miner’s behaviour, see who owns your miner’s firmware.

DATUM current status and roadmap

As of mid-2025, DATUM is deployed exclusively through OCEAN Pool. The gateway software is in active beta; the latest public release is v0.4.1beta (see GitHub releases). The DATUM Protocol specification — the encrypted binary layer between gateway and DATUM Prime — is not yet formally published; current behavior during the beta period includes pool-side block validation, with future versions aiming to remove even that exposure.

In April 2025, Tether announced it would deploy existing and future hashrate on OCEAN, a significant institutional signal that decentralized template construction is not a fringe concern.

No other major pool has implemented DATUM as of this writing. OCEAN-xyz’s GitHub organization is the canonical source for specification updates.

The DCENT_OS firmware project is tracking both DATUM and Stratum V2. Protocol support will be documented per beta image as support lands — see DCENT_OS documentation for the current feature set. DCENT_OS is currently in closed beta under GPL-3.0, with a public beta targeted for summer 2026.

Frequently asked questions

Do I need to run a Bitcoin full node to use DATUM?

Yes. A locally synchronized Bitcoin full node is a mandatory requirement for DATUM — not optional. The DATUM Gateway fetches block templates from your node via the getblocktemplate RPC. Without a local node, there is no local template to construct, and the sovereignty benefit disappears. This distinguishes DATUM from standard pool mining, where no node is needed at all.

Is DATUM the same as Stratum V2?

No. Both protocols aim to give miners control over transaction selection, but they differ in architecture. Stratum V2 is a full protocol rewrite requiring firmware support on your ASICs and a complete V2-compatible pool stack. DATUM is a proxy layer: your ASICs speak ordinary Stratum V1 to the local DATUM Gateway, which handles template construction and pool communication. DATUM works with any existing Stratum V1 hardware today, without firmware changes. Stratum V2 offers broader long-term potential — including encrypted miner-to-pool connections — but adoption depends on firmware and pool ecosystem rollout.

Can my existing Antminer use DATUM without changing its firmware?

Yes. Your Antminer (or any Stratum V1-compatible ASIC) connects to the local DATUM Gateway just as it would connect to any pool — by pointing its pool URL to the gateway’s IP and port (default: 23334). The gateway translates between the ASIC’s Stratum V1 messages and the DATUM Protocol upstream. No firmware changes are required for the miner itself. Note that some older Antminer models have a username field character limit; if your Bitcoin address plus worker name exceeds the limit, shorten the worker name suffix.

Does OCEAN see my selected transactions when I use DATUM?

No. When DATUM is operating correctly, OCEAN’s DATUM Prime server receives only merkle branches — mathematical proofs that the transactions are included — but not the transaction data itself. OCEAN cannot learn which transactions you selected or reconstruct your block’s contents from what the gateway submits. This is a deliberate privacy property of the protocol design, as documented in Section 6 of the Stratum Protocol Bible.

What happens when my miner finds a block with DATUM?

Your DATUM Gateway validates the solved block locally against your Bitcoin node’s template, then your node broadcasts the block directly to the Bitcoin peer-to-peer network. OCEAN cannot broadcast on your behalf — the pool lacks the full transaction data. This is by design: you are a first-class node operator participating in block propagation, not a passive hashrate provider. DATUM Prime receives share accounting data for reward calculation purposes.

Can I use DATUM with a Bitaxe?

Yes, with one important clarification: the Bitaxe connects to a DATUM Gateway over Stratum V1 exactly as any other miner would. The DATUM Gateway and Bitcoin full node run on separate, more capable hardware (a Raspberry Pi 4, NUC, or similar always-on machine) elsewhere on your local network. The Bitaxe itself requires no changes — you simply point its pool URL at your local gateway IP and port 23334. See the Bitaxe hub for Bitaxe-specific configuration resources.