How to Validate Work Receipts From Your Miner

A green “accepted” line in your miner log is useful. It is not a receipt for Bitcoin. It says a server accepted a submitted share under a stated difficulty. To validate work receipts, you need to establish what was submitted, who acknowledged it, what rules applied, and whether that acknowledgment can be connected to a real payout if a block is found.

That distinction matters most in solo and lottery mining. You may submit valid work for years without finding a block. The pool cannot change those odds. It can only route your work, record it honestly, and construct payment correctly if your work solves a block. Your job is to verify the parts that infrastructure can prove.

What a Work Receipt Actually Proves

A work receipt is evidence that a mining service received and accepted a specific unit of submitted work. Depending on the protocol and pool, that evidence may be a local log entry, a server response, a dashboard record, a signed ledger entry, or a combination of them.

It does not prove that you were paid. It does not prove that a block was found. It does not prove that the pool’s displayed hashrate is exact. It also does not turn a share into a claim on another miner’s rewards.

In a standard Stratum setup, your device receives a job, builds a candidate header, and sends a share when it finds one meeting the assigned share target. The server replies with acceptance or rejection. That reply is the first useful acknowledgment. But it is only as durable as the logs and records behind it.

For a solo pool, the decisive event is different. If your submitted work produces a valid Bitcoin block, the coinbase transaction in that block determines where the subsidy and transaction fees go. A pool can display a receipt for every accepted share and still fail the test that matters if the eventual block payout does not pay your address directly.

Start With Your Miner’s Own Evidence

Your miner is the first witness. Do not begin with a dashboard.

Save startup output and operational logs from your Bitaxe, NerdQaxe, ASIC, or proxy. You want a record of the configured endpoint, worker name, payout address where applicable, assigned difficulty, job notifications, submissions, and accepted or rejected responses. If your firmware can export logs, do it before a dispute exists. Logs that appear only after an argument are less useful than logs collected continuously.

Check that the worker identity sent by the miner is the identity you intended. Some pools use a Bitcoin payout address as the username. Others append a worker label after a separator. A typo can leave valid work attributed to the wrong address. The server may accept the share exactly as submitted. It cannot infer what you meant.

Time matters too. Set your local network and monitoring system to a reliable time source. You do not need nanosecond precision. You do need timestamps close enough to compare a submitted share with a server-side record and with a job change caused by a new block.

Local logs are not perfect proof. A compromised miner, flaky firmware, or interrupted serial console can produce incomplete records. They are still the evidence closest to the event. Preserve them.

Check the Connection Before You Count Shares

A receipt has limited value if you cannot establish which server received the work.

With Stratum V1, inspect the hostname, port, and transport behavior configured in the miner. Many older ASICs only speak V1. That does not make them unusable. It means you should be clear about what the connection authenticates and what it does not. Plaintext V1 exposes more of the session to the network path than encrypted Stratum V2.

Native Stratum V2 changes the security model. The miner and pool establish an encrypted channel, and authority-key pinning can let the miner verify the identity it expects rather than accepting any server that answers. Firmware such as AxeOS and BraiinsOS+ may speak V2 directly. Most existing V1 hardware needs a translator to reach a V2 service, which adds another machine and another configuration boundary to audit.

If a pool offers V1 and V2 on one reachable endpoint without requiring a translator, that removes a component for miners whose hardware supports both paths. It does not make incorrect configuration impossible. Confirm the hostname, confirm the authority key when the protocol supports it, and record the configuration you actually deployed.

Latency is also part of receipt quality. A share submitted after a job becomes stale may be rejected even though your hardware performed valid hashing work. Measure round-trip time from your network to the pool, then compare it with rejected-share reasons in the miner log. A rejection marked stale is not the same problem as an invalid nonce or malformed request.

Reconcile Accepted Shares With the Rules in Force

A meaningful validation process compares three things: your device log, the pool’s record, and the difficulty assigned to your worker at that time.

Dynamic per-rig difficulty complicates lazy comparisons. If difficulty changes, one accepted share is not always equivalent to the next one. Counting accepted lines without recording their assigned targets can create a false mismatch. The expected number of shares over a period depends on your hashrate, elapsed time, and assigned difficulty. It is statistical evidence, not a guarantee for a short window.

Look for a record that preserves enough detail to audit the acknowledgment. At minimum, it should identify the worker or payout address, a time or ordered sequence, the relevant share difficulty, and whether the submission was accepted or rejected. Better systems can expose a signed, append-only record so a later operator cannot quietly edit history without leaving cryptographic evidence.

NexusPool’s Glass Ledger is designed around that problem. A cryptographically signed public record can give miners something stronger than a changing dashboard value. The signature does not prove your hardware generated every share. Your own logs help with that. It does prove that a published record came from the signing key and has not been altered without invalidating verification.

Do not confuse a signature with a magic truth stamp. Verify which key signed the record, how the key is published, what exact bytes are covered, and whether entries are ordered or independently signed. A signature over a daily total is not the same as a signature over individual events. Either can be useful, but they answer different questions.

Watch for mismatches that have ordinary causes

Not every disagreement indicates misconduct. A reconnect can cause your miner to resubmit work. A firmware update can reset counters. A dashboard may aggregate at a different interval than your local monitor. Difficulty changes can make share counts move in unexpected ways.

Start with a narrow time window. Compare connection timestamps, job IDs if available, share difficulty, and rejection reasons. Then widen the window only after you understand the boundaries. This is slower than looking at a single hashrate chart. It produces evidence instead of a feeling.

The Block Is the Final Receipt

When a solo miner finds a block, stop treating the pool dashboard as the authority. Inspect the block.

Confirm the block hash and height through independent Bitcoin nodes or explorers you trust only as convenience tools. Obtain the raw block or raw coinbase transaction. The coinbase output should pay the address you configured before the block was found. Check the output value as well. It should reflect the block subsidy plus the transaction fees included in that block, subject to the transaction’s actual construction.

This is where direct on-chain payment changes the audit path. You do not need to prove that a pool credited an internal balance, applied a fee schedule correctly, or later approved a withdrawal. You inspect the transaction Bitcoin accepted. If the output is to your address, you control the coins under the rules of the network.

There are limits. A valid payout transaction does not prove every prior rejected share should have been accepted. It proves the outcome of the block event. That is why work receipts and payout verification are separate checks. One tracks whether your work was handled as claimed. The other verifies where a solved block paid.

Keep a Receipt Trail Before You Need One

Make evidence collection part of your mining setup. Retain miner logs, configuration backups, screenshots only as secondary context, and copies of any signed ledger data. Record firmware versions after upgrades. Keep your payout address in a plain-text configuration note so you can compare it against what the miner was actually sending.

Run occasional test windows. Pick an hour, preserve the logs, calculate the accepted-work pattern at the assigned difficulty, and compare it with the pool record. You are not trying to prove that luck owes you a result. You are checking that the machinery reports the work it received.

A pool is communications infrastructure between your hardware and Bitcoin. Its claims should be bounded by evidence. Your accepted shares deserve a receipt. A solved block deserves an on-chain transaction. Anything beyond that is a request for trust.

Trust nothing. Verify your work receipts.