Mining Custody Means Control of Your Reward

A mining pool can receive valid work from your machine without ever holding your money. That is the point of mining custody. If your rig solves a block, the question is not only whether the pool saw the share. The question is where the block subsidy and transaction fees are assigned before the block reaches the network.

For a solo or lottery miner, that destination matters more than a balance shown in a dashboard. A dashboard is a statement from an operator. A transaction output confirmed on-chain is a fact the network enforces.

What mining custody actually means

Mining custody is control over the path between a solved block and the miner's payout address. In a custodial arrangement, a service receives the block reward first. It later decides when, how, and whether to send funds onward. That can create a balance, withdrawal rules, delays, and a second payment transaction.

In a non-custodial design, the coinbase transaction for a solved block assigns the reward directly to the miner's address. The pool supplies communications and block-construction infrastructure. It does not receive a pool balance that it must later distribute.

This is a narrow claim. Direct payout does not make a machine more likely to solve a block. Network difficulty and your hashrate set that probability. The same hardware has the same chance per hash regardless of where its reward would be sent.

It also does not mean a miner has nothing to verify. A pool still provides jobs. It receives shares. It constructs a candidate block. It submits a found block to Bitcoin nodes. Each step is an opportunity for an operator to make a mistake or for an implementation to behave differently from its description. Good mining custody reduces the amount that must be taken on faith. It does not repeal the need to inspect the remaining path.

The first thing to check: the payout destination

Before connecting a miner, confirm the address that would receive a reward. Use an address you control. Keep the seed backup for that wallet offline. A direct payout is only useful if the destination remains under your control.

The destination should be visible before a block is found. Waiting for a rare event to learn where a reward would go defeats the purpose of verification. A miner should be able to compare the displayed address with the address configured on the machine, character for character.

This is especially useful for home miners. A Bitaxe, NerdAxe, or standard ASIC may sit on a shelf for months while it submits ordinary shares. That period is still time to check the wiring of the system. The address should not be a surprise reserved for a winning event.

A direct payout also avoids one specific operational dependency. There is no service-held balance that needs a separate withdrawal request. There is no later payout batch that turns the miner into a creditor of the operator. The reward output is part of the solved block itself.

There is a trade-off. A miner must manage their own address and wallet recovery. Nobody can restore access to coins sent to an address whose keys you lost. That is not a defect in self-custody. It is the responsibility that comes with it.

Shares are evidence, not money

Most shares are not blocks. They are proofs that your miner performed work at a lower difficulty target set for pool accounting and monitoring. A valid share can show that a worker was active. It cannot create a Bitcoin reward on its own.

That distinction matters when a pool records shares for a solo or lottery miner. The record should answer a simple question: did the operator count work submitted from this address? It should not be presented as a claim that a reward is owed after every share.

NexusPool signs an hourly custody receipt for each address from which it counts shares. The receipt covers exact published bytes. The miner can check those bytes against the published signing key and verify the BIP340 signature. That check establishes that the pool signed that specific record.

It has limits. A signature does not prove that a future block will be found. It does not prove that your hardware produced every hash it claims to have attempted. It does not change difficulty. What it does provide is a dated, cryptographic statement about the work the service counted for an address.

That is more useful than a number that exists only inside a web page. A web page can be changed after the fact. A signed receipt can be saved, examined, and checked against the key and message format the operator published.

A found block needs an auditable path

The rare event is where mining custody becomes real. A valid block must be preserved, submitted, and propagated before another block makes it stale. Speed matters. So does evidence of what happened.

A pool should record the found block before network submission begins. That creates a local event record before the result depends on node responses or network conditions. It should then submit to more than one independent node path when its design supports it. A node failure in one region should not be the only route between a winning hash and the Bitcoin network.

Retries matter as well. A temporary connection failure is not the same as an invalid block. The system should distinguish those outcomes instead of treating every problem as a mystery.

The same standard applies to ordinary rejected shares. A rejected share should come back with a reason. It may be stale because a new job arrived. It may fail the assigned target. It may be malformed. These cases are not interchangeable, and a vague rejection message gives a miner no way to diagnose the machine, network latency, or configuration.

None of this guarantees acceptance of a candidate block. Bitcoin nodes independently validate blocks. Another block can win the race. A direct payout address cannot fix an invalid template or reverse a stale result. It can ensure that the intended reward destination is defined before the race starts.

Protocol choice is separate from custody

Stratum V1 and Stratum V2 describe how a miner communicates with pool infrastructure. Custody describes who receives a solved reward. They solve different problems.

Many home-mining devices still speak Stratum V1. A miner should not need to alter that hardware just to use direct-to-address payout. At the same time, a device that supports native encrypted Stratum V2 should be able to use it without treating encryption as a marketing label.

For Stratum V2, verify the authority key you pin. A secure connection is only as useful as the identity it authenticates. Key pinning gives the miner a concrete value to compare, rather than a generic claim that traffic is encrypted.

Using both protocols on one port can make connection simpler for mixed hardware. It does not alter custody, hashrate, or the odds of solving a block. It only lets the miner use a protocol their machine already supports.

What to verify before pointing a miner

Mining custody is easiest to assess before your machine begins work. Check four things.

• Confirm that the payout address is your address and that a potential reward is shown as landing there directly.
• Confirm how the service records shares and whether you can validate a signed record against published bytes and a published key.
• Confirm what happens when a block is found, including whether it is written to a journal before submission and whether multiple node paths are used.
• Confirm that rejected shares include specific reasons, so you can distinguish configuration errors from normal stale work.

These checks do not require a promise about returns. They concern control, evidence, and failure handling. A miner who understands those three things can make a decision without pretending that solo mining is predictable.

The useful question is not, “Will this rig win?” No operator can answer that honestly. The useful question is, “If it does win, can I verify where the reward goes and what happened on the way there?”

Trust nothing. Verify your custody receipt.