Are Mining Pools Custodial? It Depends on Payouts

A mining pool can be custodial even when you never send it a bitcoin. The right question behind “are mining pools custodial” is simple: when a block reward is created, whose address receives it first, and who can move it after that?

That answer is not found in a pool’s logo, fee page, or payout estimate. It is found in the coinbase transaction, the accounting model, and the evidence the operator gives you before a block is found.

Custody starts where control starts

Custody means control over an asset. In Bitcoin mining, the asset that matters is a block reward. That reward includes the block subsidy and the transaction fees in the block.

A pool becomes a custodian of that reward when it receives the reward to an address it controls, records an internal balance for miners, and later sends payouts from its own wallet. The pool may pay correctly. It may have a long operating history. It still controls the coins during that interval.

That control creates a set of dependencies. The operator must keep accurate share records. It must decide when a balance becomes payable. It must sign the payout transaction. It must remain available. If the operator freezes, loses access to its wallet, applies a policy change, or makes an accounting error, the miner does not control the coins yet.

A balance shown on a dashboard is not bitcoin in your wallet. It is a claim on an operator’s future action.

This does not make every custodial arrangement dishonest or unusable. It identifies the trust boundary. A miner should know where that boundary is before pointing a machine at a Stratum endpoint.

A direct coinbase payout changes the custody answer

In a non-custodial solo or lottery arrangement, a miner supplies a payout address before work begins. If that miner solves a valid block, the block’s coinbase transaction pays the block subsidy and transaction fees directly to that address.

The pool can help construct work. It can validate shares. It can receive the solved block from the miner and submit it to Bitcoin nodes. None of those tasks require the pool to possess the reward if the coinbase output already names the miner’s address.

The distinction is visible on-chain. A miner can inspect the coinbase transaction in the found block. The output should pay the address the miner configured, not an address controlled by the pool followed by a later payout.

Direct payment removes one specific risk: the operator cannot hold the winning reward as an internal account balance because the reward never enters an operator wallet. It does not remove every operational dependency.

The pool still has a role in whether work reaches the miner quickly and whether a found block is submitted promptly. A bad job template, a lost connection, or a failed submission can matter. Those are infrastructure risks. They are not the same as custody risk, but they deserve evidence too.

Shares are not coins, but they still need proof

A submitted share proves that a miner performed work at a given difficulty. In a proportional payout model, shares are usually used to calculate a later claim on a reward. Until payment occurs, those records matter financially.

In a direct-to-miner solo setup, shares serve a different purpose. They identify which configured payout address should receive a reward if one share is also a valid network block. The pool still needs to count shares correctly. It should not ask miners to accept that count on faith.

An hourly signed receipt can make the claim testable. The receipt should bind the relevant payout address, the period, and the share-counting data in a defined byte format. The pool should publish the exact bytes covered by the signature and the public key used to verify it. A miner can then check that the receipt was signed by the expected key and that its contents match the miner’s own address and time range.

A signature is evidence of what the operator attested to at a specific time. It is not magic. It does not prove that every share reached the server if the miner has no local records. It does make later rewriting harder to hide, because the operator has made a cryptographic statement that can be checked.

NexusPool signs hourly custody receipts for each address it counts shares from and publishes the bytes the signature covers. That lets a miner verify an attestation against the pool’s published key instead of treating a dashboard number as proof.

The block template matters too

The coinbase transaction is part of the block template. It defines where the newly created bitcoin goes. Before connecting, a miner should be able to determine the destination address that would be used if their machine found a valid block.

A clear design shows that destination before any reward exists. The miner should not need to wait for a win, file a request, or trust a support answer to learn where a reward would land.

There is a limit here. A pool can show a destination address and still fail elsewhere. It might generate incorrect work. It might not preserve the winning share. It might submit a block slowly. This is why custody claims should be paired with operational details.

For a found block, useful evidence includes a durable event record before submission, submission attempts to independent Bitcoin nodes, and visible reasons when a share is rejected. An operator cannot promise that the network will accept a block. It can show what it received, what it sent, and why a server rejected a share.

Multiple submission paths reduce reliance on one node or one region after a valid block is found. They do not change the probability that a miner finds a block. Hashrate and network difficulty determine that probability.

Are mining pools custodial in every payout model?

No. “Mining pool” describes coordinated mining infrastructure. It does not, by itself, describe who controls rewards.

A pool that receives rewards first and distributes balances later is custodial for those rewards. A pool that places the miner’s own address in the coinbase transaction for a solved block is not a custodian of that reward, provided the transaction is constructed that way and can be inspected.

The answer can also vary by chain and service. Merge-mined chains have their own coinbase or reward transaction rules. A miner should check the destination and payment path for each chain separately. A non-custodial Bitcoin path does not automatically prove the same behavior elsewhere.

Protocol choice is separate from custody, too. Stratum V1, encrypted Stratum V2, and the port a rig connects to describe how mining work moves between the machine and the server. Encryption can protect a connection from certain interference. It does not by itself decide where a block reward is paid.

For home miners, this separation is useful. A Bitaxe or a standard ASIC can connect with the protocol it supports. The payout destination remains the question to settle before the machine begins hashing.

What to verify before you connect

Start with the address. Ask where the reward lands if your worker finds a block. A direct answer names your configured address and identifies the on-chain transaction where you can inspect it.

Then ask how the pool knows which address earned the work. If it uses worker names, payout-address fields, or another identifier, make sure the mapping is clear. A typo in a payout address is not a minor configuration problem. Bitcoin transactions do not have an undo button.

Check whether the pool holds any balance on your behalf. Thresholds, payout schedules, and withdrawal buttons are signs that the operator may control funds before you do. They are not automatically bad. They are a reason to understand the custody model.

Finally, look for evidence that can outlast a dashboard. Signed receipts, defined signature bytes, a published verification key, visible reward destinations, and documented rejected-share reasons all give the miner something concrete to test. A statement such as “non-custodial” is only the start of the conversation.

The point is not to demand perfection from infrastructure. Mining has latency, rejected shares, node failures, stale work, and the same hard probability at every pool. The point is to separate unavoidable network risk from avoidable trust in someone else’s wallet and records.

Configure the payout address you control. Check where a winning reward would land before your first share. Trust nothing. Verify where your reward lands.