Where Your Block Reward Goes: How to Audit Any Mining Pool

You can verify a mining pool’s fee yourself, for free, in about two minutes. Every block a pool finds contains a coinbase transaction that shows exactly how the reward was split and which addresses received it. It is public, permanent, and readable in any browser. If the website says 1% and the coinbase says 3%, the coinbase is the truth. This guide shows you how to read one — on any pool, on any SHA-256 chain, including ours.

Key takeaways

• Every block is public. The transaction that pays out a block is permanent, readable, and cannot be edited after the fact.
• The check takes two minutes and needs nothing but a browser.
• Six steps, lettered A to F. Find the block, open the coinbase, read the outputs, do the arithmetic, read the tag, repeat on a second block.
• Three ways a pool can quietly take more than advertised — all three visible in the coinbase.
• A custodial pool cannot be audited this way. That difference is the whole argument for non-custodial mining.

The audit at a glance

Why check your block reward payout at all?

Mining is one of the few industries where the customer can verify the supplier’s honesty directly, from primary evidence, at zero cost. Almost nobody does.

The reason is not laziness. It is that nobody explains how, and pools have little incentive to teach it. A pool that publishes an audit guide is inviting scrutiny it could avoid simply by staying quiet.

So here is what a pool could be doing that you would never see from the dashboard:

The third is the subtle one. The block reward is the subsidy plus every transaction fee in the block. A pool can advertise a fee on the subsidy and quietly keep the fees, and in a busy block those are substantial.

None of this is hypothetical paranoia, and none of it requires believing pools are dishonest. The point is that you do not have to form a belief at all. You can look.

What is a coinbase transaction?

The coinbase transaction has nothing to do with the Coinbase exchange. It is the first transaction in every block, and the only one that creates coins rather than moving them. Satoshi Nakamoto described it in the original paper as:

“a special transaction that starts a new coin” — Bitcoin: A Peer-to-Peer Electronic Cash System, §6

It has no genuine input — there is nothing earlier to spend — so explorers show a placeholder of zeroes where an input would normally sit. Its outputs pay the subsidy plus every transaction fee in that block, to whatever addresses the miner put in the template.

That last sentence is the whole basis of this audit. The miner chooses the addresses. On a non-custodial pool, one of them is yours.

What you need to audit a block payout

Nothing but a browser. No account, no wallet connection, no software.

Optionally, if you run a full node, the command line makes the same checks faster — there is a section on that near the end.

You will need one thing from the pool: the height of a block it found. Any honest pool publishes these. If a pool cannot or will not tell you which blocks it found, you have learned something important and can stop here.

Step A — Find the block your pool mined

You need a block height, then an explorer for the right chain.

Where to get a block height

That third method is the interesting one, because it works even when a pool publishes nothing. Every pool has an address it pays its fee to, and that address appears in the coinbase of every block it finds. Find it once and you can enumerate the pool’s blocks yourself.

The explorers

Searching by height

Paste the height into the explorer’s search box, or go directly to the block URL. The pattern is consistent:

https://mempool.space/block/<height>
https://blockchair.com/bitcoin-cash/block/<height>
https://digiexplorer.info/block/<height>
https://explorer.e.cash/block/<height>

You can also search a block hash if you have one, or an address to see everything it has ever received.

Tip. Our own block explorer lists recent blocks on all six SHA-256 chains, with pool attribution, and marks which ones we found. It is a convenient starting point, but for an audit you should finish on a third-party explorer — auditing a pool using only that pool’s own tooling defeats the purpose.

Step B — Open the coinbase transaction

Every block contains a list of transactions. The first one is the coinbase, and it is special in two ways:

It has no real input. Normal transactions spend earlier outputs. The coinbase spends nothing — it creates value. Explorers show its input as a placeholder, sometimes labelled “Newly generated coins”, “Coinbase” or a string of zeroes.

It pays out the entire block reward. Subsidy plus every transaction fee in the block, to addresses the miner chose when building the block template.

On most explorers you will find it at the top of the transaction list, tagged Coinbase or Generation. On mempool.space it sits first with a distinctive green label.

Click into it. What you want is the output list — usually labelled vout, “Outputs”, or just shown as a list of addresses with amounts.

Step C — Read the outputs: who actually got paid

A typical solo-pool coinbase has three outputs. The example below is DigiByte block 24,189,523, one of ours, decoded on a DigiByte Core v9.26.5 full node in September 2026 and checked independently on a public explorer. Open that height yourself and you should see these three lines and no others.

Decoded from a DigiByte Core v9.26.5 full node, September 2026, and verified against a public explorer. The miner’s address is shown as it appears on-chain; we do not republish anything the chain does not already make public.

Three things to understand here.

Output 0 is the miner. That address is the one the miner put in their worker username. It is not the pool’s address, and the pool never holds those coins — the network pays them directly. This is what “non-custodial” means in practice, and the coinbase is where you verify it.

Output 1 is the pool. Small, to an address the pool controls. This is the fee, taken openly and on-chain.

Output 2 pays nobody. On chains with SegWit, consensus requires a zero-value OP_RETURN output containing the witness commitment — a hash of the segregated witness data. It is structural. Exclude it from every calculation. A common mistake when auditing is treating it as a third recipient and concluding the arithmetic does not work.

Custodial versus non-custodial: what each lets you check

This is the comparison that matters, and it is not about fees.

A custodial coinbase has one spendable output, to the pool. Everything after — who mined what share, who gets paid how much, when — happens in a database you cannot see.

This is not necessarily dishonest. It is how conventional pooled mining works, and it has to, because the reward genuinely needs splitting among thousands of contributors. But it means the audit in this article stops at Step C. You can verify the pool received the block. You cannot verify anything about your share of it.

Step D — Work out the real pool fee

Now the part that actually answers the question.

The fee percentage

Add the spendable outputs — ignore the zero-value one — then divide the pool’s output by that total:

total   = 251.02252235 + 2.53558103 = 253.55810338 DGB
pool    = 2.53558103 DGB
fee     = 2.53558103 / 253.55810338 = 0.0100000  →  1.00%

Advertised 1%. Actual 1.0000%. The arithmetic closes.

Do this on your own pool’s blocks. If the result does not match what the website says, you have found something worth an email.

Checking the total against the expected subsidy

The total should equal the block subsidy plus that block’s transaction fees. The subsidy is fixed by consensus and knowable in advance:

How to read the total:

The fee-skimming check

This is the one most people miss, and it needs a block with real transaction volume.

Find a busy block from your pool. Compare:

declared subsidy         3.125 BTC
your output              3.09375 BTC   (= 99% of subsidy)
pool output              0.09 BTC
total                    3.18375 BTC

Here the total is 3.18375, so the block carried 0.05875 BTC in transaction fees. But the miner received exactly 99% of the subsidy and nothing of the fees — the pool kept all of them. The headline fee is still “1%”, and it is still a lie by omission.

An honest 1% takes 1% of the total, fees included. The DGB example above does exactly that.

Worth checking twice. Fee skimming is invisible in empty blocks, because there are no fees to skim. Always audit at least one block that carried real transaction volume.

Step E — Read the coinbase tag

The coinbase input carries a field called the scriptSig, and miners can write more or less what they like in it. Three things live there:

Most explorers decode this for you under a label like “Coinbase message” or “scriptSig (ASCII)”.

The extranonce is worth understanding on its own. It is one of the mechanisms that lets an ASIC keep working after it exhausts the 4,294,967,296 nonces in the block header — which an Antminer S21 at 200 TH/s does in roughly 21 microseconds, some 47,000 times a second. The full mechanism is in AsicBoost explained.

Treat it as a hint, never as proof. Anyone can write anything there. It is unauthenticated free text, and there is nothing stopping a miner from tagging their blocks with somebody else’s name. For attribution it is useful. For verification, the addresses in the outputs are what count.

Step F — Repeat on a second block

One block proves one block. Two blocks from different weeks, ideally with different transaction volumes, tell you whether the split is consistent.

This matters because the failure modes you are looking for are not necessarily constant. A pool that takes the advertised fee on most blocks and quietly more on some would pass a single-block check.

Four checks, ten minutes, and you know.

A complete worked example

Let us do one end to end on Bitcoin block 943,411, mined on 2 April 2026 at 21:02:41 UTC, using nothing but an explorer — no node, no account, no software. Every figure below is on-chain and still there today.

We have deliberately picked a block that is not ours. SoloFury has never found a Bitcoin block, and at Bitcoin’s difficulty that is the expected outcome for a pool our size. This one was found by a solo miner running roughly 230 TH/s through solo.ckpool.org, which advertises a 2% fee. The method does not care whose block it is, and auditing someone else’s is a better demonstration than auditing our own.

A. Find it. Go to mempool.space/block/943411, or blockstream.info/block/943411, or any Bitcoin explorer you already trust. Block hash 00000000000000000000bef7f0870c24f2962cf83949e96c7288cf30f0d74bf0, 3,961 transactions, difficulty 133,793,147,307,542.

B. Open the coinbase. First transaction in the list, txid 2b38af3b910506c4aa436a4db48f1a1be4e35d245ce4abe0b4bc6a6c4667a582. One input, pointing at the all-zeroes placeholder that marks a coinbase and can point nowhere else.

C. Read the outputs. Three of them:

3.07626305 BTC  ->  bc1qtt7cr9cxykyp9g4hq47zf5lq9t97cxvq72lun3
0.06278087 BTC  ->  bc1q28kkr5hk4gnqe3evma6runjrd2pvqyp8fpwfzu
0.00000000 BTC  ->  OP_RETURN (witness commitment)

D. Arithmetic.

spendable total  = 3.07626305 + 0.06278087 = 3.13904392 BTC
pool share       = 0.06278087 / 3.13904392 = 2.0000%
subsidy at 943,411                          = 3.12500000 BTC
transaction fees = 3.13904392 - 3.12500000  = 0.01404392 BTC

The pool share is 2.0000% to four decimal places, against an advertised 2%. The total exceeds the subsidy by exactly the block’s transaction fees, which means the fees were passed through and not skimmed. The miner’s address received the rest directly from the network.

E. Tag. The scriptSig begins 0333650e, which is the BIP 34 height push: strip the length byte, reverse 33650e to 0e6533, and you get 943,411 — the block confirms its own height. Further along, two runs of bytes decode to readable ASCII: ckpool and /solo.ckpool.org/. The block says who built it.

F. Repeat. Do the same on any other block carrying that tag. If the percentage moves between blocks, or if it holds on empty blocks and drifts on full ones, you have found something worth asking about.

That is the whole audit, on the chain that matters most, on a block we had nothing to do with. Nothing above required trusting us, the pool that found it, or the explorer — three independent explorers will return the same bytes, because they are reading the same chain.

Red flags in a coinbase transaction

What you are looking for, in rough order of severity.

The last row is worth dwelling on. A tag saying SoloFury in the coinbase of a block that pays a completely different address proves nothing about who found it or who got paid. Always finish on the outputs.

The other check: what your miner sees before a block exists

Everything above audits a block that has already been found. There is a second check, and it runs continuously, before any block exists.

Every stratum job arrives in a mining.notify message, and that message carries the coinbase transaction the pool wants you to hash. The payout addresses are already inside it. Your miner can therefore decode the work it is given and tell you, in real time, whether you are in it.

The AxeOS banner

Since firmware 2.13.0, released on 20 February 2026, AxeOS decodes that coinbase and matches every output address against the address in your stratum user field. When none of them match, the dashboard shows a yellow banner reading “You don’t have a share in the coinbase reward.”

That banner set off a wave of alarm across the home mining community, most of it unfounded. It fires for five quite different reasons, and only one of them is a problem:

The last row is the one that catches people, and it is worth being blunt about because it applies to us. On our Bitcoin endpoints the banner must not appear — your address is in the coinbase by construction, and if it is missing, something is wrong and we want to hear about it. On our Bitcoin Cash, DigiByte and eCash endpoints it will appear, and it is a false positive. The coinbase pays your bitcoincash:, ecash: or DigiByte address, which the parser was never written to recognise. You can switch off Decode Coinbase Tx in the advanced pool settings — or, better, verify the block on an explorer using the method above, which works on every chain and does not depend on what your firmware can parse. Hash-donation pools trigger the same false positive for a different reason; the 256 Foundation model is a deliberate donation of hashrate, not a payout failure.

Why the check was written

In February 2026 a community researcher documented two solo mining pools that advertised Bitcoin solo mining while handing their miners Bitcoin Cash work and keeping the proceeds. The miners ran perfectly and earned nothing. The evidence came from monitoring sixteen pools simultaneously over an eleven-minute window and comparing the prevhash — the previous block hash — in the work each pool was distributing. A pool mining Bitcoin Cash distributes a Bitcoin Cash tip. It cannot fake that, because the tip is the chain.

We are not naming the two pools. The evidence is public, the firmware change that followed is public, and which pools they were matters less than the fact that the failure mode exists and went unnoticed for a while. What matters to you is that two independent checks now exist and neither requires trusting anybody:

Run both. They answer different questions and neither substitutes for the other. The firmware check tells you that the work you are doing is the work you think you are doing. The explorer check tells you what happened when that work finally won.

Doing it from the command line with bitcoin-cli

If you run a full node, the same audit is three commands. Substitute your chain’s CLI — bitcoin-cli, bitcoin-cash-node-cli, digibyte-cli — the RPC interface is the same on all of them.

# 1. height -> hash
HASH=$(bitcoin-cli getblockhash 957382)

# 2. block with full transaction data; the coinbase is tx[0]
bitcoin-cli getblock $HASH 2 | python3 -c "
import sys, json
b = json.load(sys.stdin)
cb = b['tx'][0]
tot = sum(o['value'] for o in cb['vout'] if o['value'] > 0)
for o in cb['vout']:
    if o['value'] > 0:
        addr = o['scriptPubKey'].get('address', '?')
        print('%14.8f  %6.3f%%  %s' % (o['value'], o['value']/tot*100, addr))
print('total spendable: %.8f' % tot)
"

That prints every spendable output with its share of the total, which is Steps C and D in one go.

There is a second reason to run a node, unrelated to auditing pools. Bitcoin Core’s own source states the maturity rule plainly:

“Coinbase transaction outputs can only be spent after this number of new blocks” — bitcoin-core/src/consensus/consensus.h

That number is 100 — roughly 17 hours on Bitcoin, about 25 minutes on DigiByte. It is a consensus rule, not a pool policy, and no pool can shorten it for you.

Without a node, blockchair.com and mempool.space both expose block data as JSON through free public APIs.

Chain-specific quirks: Bitcoin, Bitcoin Cash, DigiByte, eCash

The method is identical everywhere. The arithmetic has three exceptions worth knowing.

On eCash, a coinbase showing you 58% of the total is not a pool taking 42% — it is the chain working as designed, and the pool fee comes out of your 58%. Full breakdown in eCash explained for miners.

What a coinbase audit cannot tell you

Honesty requires stating the limits.

A pool claiming more blocks than it found would be caught by this method immediately. A pool quietly finding fewer than it claims looks the same as bad luck.

What the audit proves conclusively is the split — the number most likely to be misrepresented, and the easiest to check.

Why non-custodial payouts are the only verifiable ones

Non-custodial solo mining has one genuine structural advantage, and it is not the fee. It is that the payment happens in the same transaction that creates the coins, to an address you chose, in public, permanently.

There is no balance held on your behalf. There is no withdrawal to request, no threshold to reach, nothing to lose in an exit or a hack — because at no moment does anyone but you hold your coins. For what that means the day you actually win, see you found a block, now what.

That property is worth something only if somebody checks it. Now you can.

If you are still choosing a pool, how to choose a solo mining pool covers what else to look at, and solo mining vs pool mining covers the structural difference this audit exposes.

And if you want to audit us specifically: our blocks are listed on the pool dashboard with heights. Take any of them, open a third-party explorer, and check. We would rather you did.

Sources

Protocol specifications. BIP 34 — block height in the coinbase, active since 2013. BIP 141 — SegWit, and the witness commitment output. BIP 320 — version bits available for rolling.

Consensus code. bitcoin-core/src/consensus/consensus.h for COINBASE_MATURITY; GetBlockSubsidy in validation.cpp for the halving schedule.

Original paper. Bitcoin: A Peer-to-Peer Electronic Cash System, Satoshi Nakamoto, 2008 — §6 on the coinbase.

Explorers. mempool.space, blockchair.com, digiexplorer.info, explorer.e.cash.

Firmware. The coinbase parser shipped in AxeOS / ESP-Miner 2.13.0 on 20 February 2026. Reported behaviour, including the expected false positives on donation pools, testnet and non-Bitcoin chains, is documented in the project’s own issue tracker — see ESP-Miner issue #1570, issue #1649 and discussion #1560.

Example data. Bitcoin block 943,411, mined 2 April 2026, read from the public Blockstream and mempool.space APIs and reproducible from any Bitcoin full node; the block was found through solo.ckpool.org, not by us. DigiByte block 24,189,523, decoded from a DigiByte Core v9.26.5 full node and verified independently on a public explorer, September 2026. Subsidy figures current at time of writing — verify against the height you are auditing, not against the table above.