Who decides what goes in the block?
DATUM mining is a protocol and gateway setup where miners pool rewards but build their block templates through their own node. That is how OCEAN's DATUM documentation frames it, and the rest of this article unpacks what it means in practice.
Start with the term that matters most: the block template. A block template is the draft block a miner works on. It lists which transactions will be included, adds the payout details, and leaves room for the hashing hardware to search for a valid proof of work. Nobody can find a block without one.
The block reward is the block subsidy plus the fees paid by the transactions inside the block. Whoever builds the template decides which waiting transactions get in and which are left out. That is the real power at stake, and it is separate from who owns the hashing hardware or who receives the payout.
A solo miner who runs their own node uses the node's getblocktemplate RPC to get a draft built from the transactions that node has seen and verified. Solo mining keeps template control with the miner, but the reward is lumpy: payments are large and infrequent, which is higher variance. Pooled mining can reduce payout variance by distributing proceeds under the pool’s share-accounting and payout method, usually in rough relation to contributed work.
The usual trade is that joining a pool means taking the pool's work. DATUM is an attempt to break that link, so a miner can pool rewards without handing transaction selection to the pool.
We back that direction: miners should build templates through their own nodes, and pooling need not surrender that choice. Part 1 of this series covers why template control matters in more depth. This article stays on how DATUM works and where its limits are.
A pool-supplied job versus the node-to-gateway-to-miner path
In the conventional arrangement, the pool's servers build the template and hand miners a pool-supplied job: ready-made work derived from that template. Your hardware hashes and returns proof of work. You never see or influence the transaction list, so the pool, not you, decides what goes in the block. Nothing in the pooling itself requires this. It is simply how most pool setups work.
With DATUM, the work is split differently:
- Your node verifies the chain and builds the template, which is where transactions are chosen.
- A gateway takes that template and handles communication with the pool.
- Your mining hardware does the hashing.
The gateway is the key addition. Mining hardware generally speaks to a single endpoint and does not talk to a full node directly, so the gateway sits between them. It lets hardware keep working as normal while the template comes from your node instead of the pool.
| Pool-supplied job | Node-to-gateway-to-miner path | |
|---|---|---|
| Who builds the template | The pool | Your own node |
| Who chooses transactions | The pool | Your local node, under its configured template-selection policy |
| Role of the gateway | Not needed | Passes your template along and handles pool communication |
| Role of your hardware | Hashes the work it is given | Hashes the work it is given |
| Who coordinates rewards | The pool | The pool |
The last row is the point of the design. Template construction and reward coordination are different jobs, and DATUM lets them live in different places.
One caveat belongs here. Running your own node means you are responsible for keeping it synced and reachable. Full nodes download and verify every block and transaction before relaying them, so the node you run is doing real work, not just forwarding what someone else says.
What the pool still does
A mining pool combines the computing power of many miners so that the group finds blocks more often than any one member would. The reward is then split among members, and that is what smooths out the variance of solo mining.
To do this fairly, the pool needs a way to measure each member's contribution. Miners submit shares: proof-of-work results that show how much work they are doing, even when they do not solve a block. A payout system then distributes rewards according to hashing power and the shares submitted. Different pools use different payout methods, such as PPLNS, which bases payouts on the shares contributed around the time the pool finds a block.
Under DATUM, that coordination role stays with the pool:
- receiving and counting your shares;
- keeping the accounting of who contributed what;
- distributing rewards when blocks are found, under the pool's own payout rules.
What the pool no longer does, in the DATUM design, is decide which transactions your hashing power commits to. That distinction is the whole idea: the pool coordinates the money, while you keep control of your node's template policy.
The exact mechanics of how shares and payouts are handled belong to each pool and its published terms, so check the pool's own documentation rather than assuming. For a framework on comparing those terms, see our guide on how to choose an XBT mining pool, and the published pool terms we track.
What DATUM does not promise
DATUM changes who builds the template. It does not change everything else about mining. Treat each of the following as something to verify, not something the protocol hands you.
- Pool compatibility. A protocol is only useful if the other side speaks it. A pool has to choose to support DATUM miners. You cannot assume that any pool will accept your template.
- Independent fallback. If your node or gateway goes down, what happens next depends on your setup and the pool's terms. Some pools may route you to their own pool-built work instead, possibly under different terms. That is a different arrangement from the one you set out to run, and it is the pool's template again. Read the pool's published terms on failover before relying on it.
- Payouts. The pool still handles reward distribution. DATUM does not guarantee that a pool pays on time, pays at all, or pays in a way you would like. You are still trusting a counterparty with that part.
- Uptime. Your node, your gateway, your network connection and the pool's servers all have to be working. More moving parts under your control means more things you must keep running.
- Immunity from censorship. Building your own template stops a pool from choosing your transactions for you. It does not stop other miners or pools from excluding transactions in their blocks, and it does not guarantee that a transaction will be mined quickly.
We think the trade is worth making, and we favor pools that coordinate rewards while miners keep template control. But the case for it is the mechanism, not a promise of safety or profit. Choosing a pool still affects revenue, payout frequency and counterparty risk, whichever template model you use.
Some community discussion suggests that a pruned node can be enough for solo mining with the DATUM gateway. That is a reader report, not a verified fact, so check current documentation for the version you plan to run.
SHA256d DATUM deployments and the BLAKE2b CONVOY gateway
Two things often get blurred together: the DATUM protocol and the software or pools that use it on a particular chain.
The original DATUM protocol and its SHA256d deployments. DATUM was introduced for Bitcoin, which uses SHA256d proof of work. OCEAN is the example deployment, and OCEAN's DATUM documentation is the primary source for how the protocol is described. SHA256d Bitcoin can support miner-built templates, and DATUM is a case of that. The point of difference is between miner-built templates and centrally supplied ones, not between BTC and anything else.
The CONVOY gateway for BLAKE2b. Bitcoin BLAKE2b (XBT) is a separate chain with a different proof-of-work hash function. CONVOY is the chain-specific gateway described in the Bitcoin BLAKE2b miners documentation and mining documentation as compatible with DATUM for that chain. Its behavior, options and requirements are defined by its README and source code, so read the version-dependent documentation for the release you run. This article does not reproduce them, and details can change between versions.
| Original protocol and SHA256d deployments | BLAKE2b CONVOY gateway | |
|---|---|---|
| Chain | Bitcoin (SHA256d) | Bitcoin BLAKE2b (XBT) |
| Example source | OCEAN's DATUM documentation | The BLAKE2b miners page and the gateway's versioned README and source |
| What it is | The protocol and its deployments | A chain-specific gateway compatible with DATUM |
A different hash function does not by itself make mining more decentralized. What matters for miner independence is who builds the template, and that is a question about the arrangement, not the algorithm. Naming a chain or a pool "BLAKE2b" does not prove that miners control their templates. Our live dashboard does not measure template ownership either, so treat it as network observations, not proof of decentralization.
This is a description of the setup, not an endorsement of any chain, gateway or pool. If you are weighing options, start with the pool terms we publish and our guide on how to choose an XBT mining pool.
Questions readers ask next
Is DATUM only for pooled mining? Community discussion describes the gateway as usable both with a pool and without one. Those are different modes with different reward arrangements, so do not mix them up. This article covers the pooled case, where the pool still coordinates rewards. Check the documentation for the mode you intend to use.
Why do small miners get confused about difficulty and share settings? Reader reports show that low-hashrate users sometimes see a higher pool difficulty than they expected. That is a pool and device setting question rather than something DATUM itself defines. Check your pool's published guidance before assuming a fault.
Do I need to run a node to use this? Yes. The template comes from your own node. How much of the chain that node must keep is a setup detail to check in current documentation.
What is the short version? A pool-supplied job means the pool builds the template. The node-to-gateway-to-miner path means your node's configured policy builds it, while the pool still counts shares and distributes rewards. DATUM makes that possible, but it promises nothing about pool support, fallback, payouts, uptime or censorship.