Self Custody Mining Review: Verify the Pool

A self custody mining review should begin at the only moment that matters: a block is found. Where do the subsidy and transaction fees go? If the answer is an internal balance, a scheduled withdrawal, or a payment request you must submit later, the pool has custody somewhere in the path. A pool can call itself non-custodial and still require you to trust its accounting before your coins reach an address you control.

Solo mining does not produce steady income. A small miner may never find a block. That is not a pool defect or a problem that better wording can fix. The question is narrower and more useful: if your hardware does solve a valid block, can you establish that the payout was constructed for your address before the pool had a chance to retain it?

What a self custody mining review must test

Self-custody is not a logo, a withdrawal threshold, or a promise that funds are "safe." It is a property of the payout path. For Bitcoin solo mining, the strongest version is straightforward: the coinbase transaction in the solved block pays the full block subsidy and the included transaction fees directly to the payout address specified by the miner.

That construction removes the pool's internal wallet from the reward path. There is no balance for the operator to credit, no batch payment to wait for, and no pool-side withdrawal approval. The block reward appears on-chain at the address that was named before the winning hash arrived.

That does not mean the pool disappears from the process. A mining pool supplies work, receives shares, validates work, and submits valid blocks to the network. Those jobs require software and operational competence. Self-custody means the pool should not become the owner of the coins while performing them.

A useful review separates these two questions. First, can the pool take custody of a block reward? Second, can you independently check that it counted and handled your work as claimed? Direct payout addresses answer much of the first question. Verifiable job and share records address the second.

Inspect the coinbase, not the dashboard

Dashboards are convenient. They are not proof of a payout. A displayed balance is a database entry controlled by the service displaying it. It can be accurate, inaccurate, delayed, or unavailable. None of that changes the Bitcoin chain.

The payout check starts with the candidate block template. Look for a preflight or equivalent mechanism that shows the intended coinbase output before you commit hash rate. Confirm that the output script corresponds to your own Bitcoin address. Confirm the stated reward amount reflects the block subsidy plus the fees from the selected transactions, less only deductions that are explicitly present and understandable.

After a block is found, inspect the published block and its coinbase transaction. The output should pay your address directly. This is stronger evidence than a notification email, a pool balance, or an operator statement because the transaction is part of Bitcoin's shared ledger.

There are limits. A pool cannot make a low-hashrate miner more likely to find a block than the math permits. It also cannot promise which transactions will be available for a future template. What it can do is let you verify the payout construction for the work it sends you. That is the claim worth testing.

Zero fee needs a precise meaning

"Zero fee" is often treated as a complete answer. It is not. Ask what the pool is allowed to deduct and where a deduction could occur.

For a solo block, the relevant arithmetic is visible in the coinbase transaction. Bitcoin creates the subsidy under the consensus rules. The transaction fees come from the difference between the inputs and outputs of included transactions. If a pool advertises zero fees, the reward output should make its handling of those values legible rather than requiring trust in an off-chain calculation.

Network transaction fees are separate from pool fees. If you later spend the mined output, your wallet will select a fee for that transaction. That cost belongs to your own transaction, not the mining pool. A good review keeps these categories separate, because vague fee language is where unnecessary trust tends to hide.

Shares still matter when payouts are direct

Some miners assume shares are irrelevant on a solo pool because a share is not a payout claim. Shares still matter. They are evidence that your device received work and returned results meeting the assigned share target. They help detect a bad connection, an invalid worker configuration, rising latency, or a device that is quietly submitting nothing.

A pool should make its work accounting testable. Dynamic per-rig difficulty is useful because an ESP32-class miner and a conventional ASIC do not produce shares at the same rate. Difficulty that is too high can leave a small miner waiting so long for a share that troubleshooting becomes guesswork. Difficulty that is too low can create needless protocol traffic.

The review question is not whether every miner gets the same share difficulty. It is whether the assigned difficulty, accepted shares, rejected shares, and worker identity are visible enough to investigate. When a rig reports accepted work locally but the pool reports none, you need evidence from both sides, not a vague instruction to reboot it.

Connection security is part of ownership

A direct coinbase payout is only useful if an attacker cannot alter the payout address in transit or direct your hashrate somewhere else. Mining protocol security is therefore part of a self-custody review.

Stratum V1 remains common, especially with older ASICs and hobby hardware. It can work well when configured carefully, but miners should know what endpoint they are using and how worker names encode the payout address. A mistyped address is not an abstract configuration error. It can turn a winning block into someone else's output.

Native Stratum V2 gives miners a stronger set of tools, including encrypted connections and authority-key verification where implemented. That matters for firmware such as Bitaxe AxeOS and BraiinsOS+ that can speak V2 directly. Many other rigs need a translator to reach a V2-only pool. A service that accepts V1 and V2 on one port can remove that extra moving part for miners whose hardware is not V2-native.

Encryption alone does not prove that you reached the intended pool. Key pinning and published connection details give you something concrete to compare. Verify the hostname, port, and any authority key from a trusted source before pointing a fleet at it. Do not copy pool settings from a random forum screenshot. That is how an ordinary configuration step becomes a custody failure.

Check the operator's claims against artifacts

The strongest mining infrastructure claims leave artifacts behind. Look for signed records, versioned changes, raw job details, and payout data that can be checked without special access. A public changelog tells you what changed and when. A cryptographically signed ledger can establish that a published record has not been silently rewritten after the fact.

NexusPool is one example of this model. Its Bitcoin solo service supports Stratum V1 and native encrypted Stratum V2, constructs direct on-chain payouts to the miner's address, and publishes a signed Glass Ledger for records it exposes. Its Payout Preflight is the right kind of feature because it directs attention to the intended coinbase output before the rare event everyone is waiting for.

Treat any such feature as an invitation to verify, not a reason to stop verifying. Check the signature format, retain the relevant records, and compare the actual solved-block transaction with the preflight data. A signature is meaningful only when you know which key made it and what exact data it covers.

Latency is operational, not cosmetic

For lottery mining, latency does not change the probability attached to each hash your miner actually performs. It does affect how long a miner works on a job after the network has moved on. Stale work cannot solve the current block. A miner with intermittent Wi-Fi, DNS problems, or an overloaded local network can lose useful time without producing an obvious hardware alarm.

Measure your own path. Compare ping and connection behavior across available endpoints. Watch stale and rejected share rates over enough time to avoid reacting to a brief network hiccup. If a pool offers multiple points of presence, use the endpoint that produces the more stable route from your location, not the one with the more appealing city name.

The practical standard is simple. Your miner should know where its work comes from, what address a solved block will pay, how its submitted work is acknowledged, and how to verify the final transaction independently. Anything else may still be convenient. It is not self-custody in the strict sense.

Trust nothing. Verify the payout transaction.