Do You Need a Pool to Solo Mine?

You cannot point a mining device at a Bitcoin node and mine. An ASIC speaks Stratum, a node speaks RPC, and something has to sit between them building block templates and handing out work. Solo CKPool says so on its own front page. So the real question is not pool or no pool. It is whose pool software, running on whose hardware, maintained by whom.

That reframing matters, because it turns a loyalty question into an engineering one. Here are the three real architectures, what each genuinely gets you, and the failure modes that the setup guides tend to mention in a footnote.

Key takeaways

• There is no configuration without pool software. Self-hosting means running it yourself, not doing without it.
• Your own node does not improve your odds. Odds depend on hashrate and difficulty only. Self-hosting can lower effective odds through downtime and stale work.
• What it does buy is template control — deciding which transactions go into the block you are trying to find. That is a real and meaningful thing to want.
• Stale work is the main technical risk, and the DATUM documentation flags it explicitly: without prompt new-block notifications your hardware hashes for nothing.
• Hosted pools run multiple geographic endpoints with automatic failover. Your home node has one endpoint, and it is your home internet connection.
• DATUM is the middle path: your templates, someone else’s share accounting. Beta software, Linux only, Bitcoin only.

Why you cannot mine straight to a node

This is the part that surprises people, and it is worth being precise about because everything else follows from it.

A Bitcoin node’s job is to validate and relay. It exposes an RPC interface, and one of the calls it offers is getblocktemplate, which returns a candidate block: the header fields, the transactions to include, and the rules the result must satisfy. It does not hand out work to miners, track who submitted what, adjust difficulty per device, or assemble a submitted share back into a block.

Your ASIC, meanwhile, speaks Stratum. It expects a server to send it a job, tell it what share difficulty to work at, accept its submissions, and notify it when the job changes.

Between those two sits a stratum server. Solo CKPool describes itself this way on its own site: not a pool despite the name, but a service that exists because you cannot mine directly to a Bitcoin Core node. That is the accurate description of what every option on this page is, including the ones you run at home.

The three architectures

None of these is the “real” way to solo mine. They are different distributions of control and responsibility, and the right one depends on which of those you actually want more of.

What self-hosting genuinely gets you

This section deserves to be made properly, because the case is real and the rest of this article is only credible if it is.

Transaction selection. Whoever builds the template decides which transactions go into the block. When a handful of pools construct most templates, that is a real concentration of power over what Bitcoin confirms. Building your own template moves that decision to you. This is the strongest argument in the whole discussion and it is not a marketing argument, it is a structural one. Our Stratum V2 explainer covers why the protocol layer is being rebuilt around exactly this problem.

Privacy. A hosted pool knows your address, your hashrate and your uptime. A local stratum server tells no one anything.

No fee. Self-hosting has no percentage attached. On a lottery outcome that is the difference between the full reward and the reward minus a slice.

Verification by construction. With your own node you are not trusting anyone’s claim about what you are hashing on. You built the template; you can read it.

It is genuinely educational. Running a node, a stratum server and a monitoring front end teaches more about how Bitcoin works than any amount of reading. Several excellent community guides exist for exactly this, on Umbrel, on Start9, on plain Ubuntu, and in Docker on Windows.

If those things are what you want, self-hosting is the correct answer and nothing below should talk you out of it.

What it costs, from the documentation

Every item here comes from the projects’ own requirements or from the behaviour they warn about, not from speculation.

1. Stale work is the real risk

When a new block is found anywhere on the network, every template built on the previous one becomes worthless instantly. Your stratum server has to learn about that within milliseconds and push new work, or your hardware keeps hashing against a dead job.

The DATUM Gateway documentation addresses this directly, instructing operators to configure their node to send block notifications to the gateway specifically to avoid mining stale work. That configuration is a line in bitcoin.conf and a dependency package. Get it wrong and nothing visibly breaks: your dashboard shows a healthy hashrate, your temperatures look fine, and you are producing nothing.

This is the failure mode that most resembles the zombie-pool problem home miners already know from the hosted world, except that here you are the one responsible for detecting it.

2. Failover is not free

Solo CKPool runs endpoints in the USA, Europe, Asia and Oceania, selects the lowest-latency one automatically, and fails over if that endpoint goes down. That redundancy is invisible when it works.

Your self-hosted stack has one endpoint. If your node crashes, your power flickers, or your ISP has a bad hour, your miners have nowhere to go unless you configured a fallback — and the only sensible fallback is a hosted pool, which is a slightly awkward but entirely reasonable place to end up.

3. The machine is a real machine

The DATUM Gateway’s stated requirements are a Linux system, a fully synced Bitcoin full node with Knots recommended, fast storage, a stable connection, a CPU able to validate incoming blocks without delay, and roughly 1 GB of RAM on top of the node’s own needs. Underneath that sits a full node: hundreds of gigabytes of storage and an initial sync measured in days.

None of that is exotic. It is also a second appliance running continuously, drawing power, needing updates, and occupying attention. If you are running a 15 W miner and a 40 W node to support it, the node is now the larger part of your electricity bill.

4. Configuration mistakes are silent and expensive

The DATUM setup requires reserving block space for the generation transaction, and its documentation is explicit that without that reservation your work will not be able to fit a reward split. That is a config line whose absence you would discover at the worst possible moment.

The general shape of this risk is what makes self-hosting different in kind from a misconfigured miner. A wrong pool address on a hosted setup gets rejected immediately. A subtly wrong template configuration produces valid-looking work right up until the moment it matters. Our post-win guide covers what should happen in the minutes after a block, and the answer assumes the plumbing was correct beforehand.

5. Beta software, narrow platform

DATUM Gateway is at v0.4.1beta, supports Linux only, and supports Bitcoin only. Its own release notes state that other operating systems may work but are at your own risk. That is honest labelling from the project, and it should be read as written.

For the four SHA-256 chains beyond Bitcoin, DATUM is not an option at all. A fully self-hosted ckpool-style stack can serve them, but then you are running a node per chain.

6. You are the operations team

This is the one nobody quantifies and everybody eventually feels. A hosted pool’s uptime is somebody’s job. Your node’s uptime is a thing you remember to check, until the week you are travelling.

The uptime arithmetic

Here is the part worth doing on paper, because it is the only way to compare a fee against a risk.

Odds scale linearly with time spent hashing on valid work. A device that is offline, or working a stale template, is buying nothing during that period. So downtime is a straight percentage reduction in your effective hashrate.

The comparison is not perfect, because a fee is taken from a reward you actually won while downtime reduces the chance of winning at all. But as a rule of thumb it is useful: if self-hosting costs you more than a percent or two of uptime, the fee you avoided was the cheaper option.

Whether it does depends entirely on you. Someone running a node on a UPS with monitoring and alerting will beat that easily. Someone running it on a spare laptop that sleeps when the lid closes will not.

Who should self-host

Three profiles, honestly drawn.

1. You want template sovereignty and you mean it. If transaction selection is the reason, self-hosting or DATUM is the only answer and the operational cost is the price. This is the strongest case and it does not need any other justification.
2. You already run a node. If a synced node is already humming on a UPS, the marginal cost of adding a stratum layer is small and you have most of the reliability problem solved.
3. You want to learn how it works. Building the stack once teaches things nothing else does. Consider running it alongside a hosted fallback rather than instead of one.

Reasons to use a hosted solo pool instead, equally honestly.

• You want the odds without the operations. Your hashrate is the only thing that changes your chances, and a hosted pool lets you spend all of your attention on that.
• You mine more than one chain. Self-hosting five chains means five nodes.
• You cannot guarantee uptime. Travel, unreliable power, shared internet: all of these cost more than a fee.
• You want failover that already exists rather than one you have to build.

These are not mutually exclusive, and the most robust home setup is usually a mix: self-hosted primary where sovereignty matters, hosted fallback configured so that a node problem does not become dead hardware. Every AxeOS-family device supports a fallback stratum host, and configuring one costs nothing.

What actually matters either way

Two things survive the whole argument.

Whoever builds the template decides what Bitcoin confirms. If decentralisation is your reason for solo mining, that is the lever, and it is available through DATUM without running the entire stack yourself.

Whoever holds the reward decides whether you get it. A block paid directly in the coinbase to an address you control needs no claim, no withdrawal and no trust. That is true of a self-hosted setup and it is true of a non-custodial hosted pool. It is not true of everything on the market, which is why our seven criteria for choosing a solo pool puts verifiable non-custodial payout second on the list.

Between those two, the question of whose machine runs the stratum server is a question about operations, not about principles. Answer it with the honest assessment of your own uptime, not with the one you would like to be true.