Accepted vs Local Hashrate: What Miners Should Trust

Accepted vs local hashrate compares two different estimates. The miner dashboard estimates work produced inside the device, while a pool estimates productive work from shares it receives and accepts. Short windows can diverge through normal statistical variation, variable share difficulty, latency, stale work, rejected submits and different averaging rules. A useful diagnosis aligns worker identity, units, clock and time window, then checks accepted and rejected shares alongside temperature, board status, power and network events. This article is a reconciliation method, not another general guide to advertised ASIC hashrate.

Why the two hashrate figures differ

Reassess accepted vs local hashrate whenever network conditions, firmware, tariffs or official guidance changes.

An ASIC controller can estimate hashrate from chip work, nonces, valid internal results or firmware-specific counters. This local figure is useful for seeing whether boards and chips are active, but it cannot confirm that the intended pool received and credited the work.

A pool cannot inspect every hash attempted inside the machine. It estimates effective hashrate from submitted shares and their assigned difficulty. Accepted hashrate therefore measures a communication and accounting outcome: the device produced qualifying work, sent it to the target in time and the target accepted it for the named worker.

Both are estimates with their own windows and definitions. A five-minute pool reading can move sharply even while the local dashboard appears steady. Over a longer stable period, the figures should converge within normal variance and known losses, but they need not display the same number at every moment.

Match identity, units and time windows first

When reviewing accepted vs local hashrate, separate measured facts from forecasts so the result can be reproduced.

Confirm that one physical miner has its own worker name. If several devices share one worker, the pool view aggregates them and cannot be reconciled against a single local dashboard. Check that a failover pool, proxy or firmware fee route has not diverted part of the time or work.

Normalise units before calculating a percentage. A pool may report GH/s, TH/s or PH/s, while management software may label a chart differently. Also record the site’s time zone, daylight-saving setting and the exact start and end timestamps used by each system.

Choose an interval appropriate to share arrival. Braiins Pool documents five-minute, sixty-minute and twenty-four-hour worker figures. A low-hashrate worker can submit shares irregularly, so its short-window estimate is particularly noisy. Use at least several hours for an initial comparison and a full stable day when assessing billing or sustained delivery.

Understand shares, difficulty and variance

A share proves that a miner tested enough work to find a hash below the pool’s easier share target. Variable difficulty changes the amount of represented work per share so that different miners can submit at a manageable rate. Counting shares without their difficulty can therefore misstate contribution.

Share discoveries are probabilistic. Even with a stable underlying hashrate, one window may contain more or fewer shares than its expectation. This is not the same as Bitcoin block luck, but it follows the same principle that random qualifying results do not arrive at perfectly even intervals.

Extend the window before tuning the miner to chase a short dip. If the accepted estimate remains consistently below local output, quantify accepted, stale, duplicate, invalid and rejected work where the pool or proxy exposes those categories. The pattern is more diagnostic than one effective-hashrate number.

Diagnose a persistent gap

Start at the device. Check board count, chip errors, temperatures, fan or pump state, frequency, voltage profile, power and restart history. A local aggregate can conceal one unstable board if the display smooths the result or reports an expected figure rather than accepted internal work.

Then follow the route. Verify DNS, gateway, packet loss, latency, proxy capacity, pool endpoint and worker credentials. Frequent target switching, stale jobs, an overloaded proxy or intermittent internet can lose productive work after the miner has counted it locally.

Finally inspect the target response. Authentication failure, duplicate submissions, low-difficulty shares, stale work and unsupported protocol details have different causes. Preserve the miner log, proxy log and pool export for the same interval. Screenshots taken at unrelated times are difficult to reconcile.

Set a defensible reconciliation process

Capture local hashrate, pool accepted hashrate, rejected work, uptime, power and temperature at a fixed interval. Keep raw data rather than only daily screenshots. A fleet dashboard should preserve worker identity across firmware changes and replacements so a historical series does not silently join different machines.

Define the denominator when reporting loss. Rejected percentage based on submits can differ from a percentage based on difficulty-weighted work. Use the pool or protocol definition and document it. Avoid subtracting two rounded dashboard values and presenting the remainder as stolen hashrate.

For hosted equipment, agree which data governs billing and what happens during a monitoring outage. Customer-facing pool credentials or read-only access can support transparency, but access permissions, personal data and account security still need control.

When to escalate or change configuration

Escalate when a matched long-window comparison shows a repeatable shortfall, rejects exceed the operator’s normal baseline, workers miss shares, or the gap begins with a recorded change. Provide serial, worker name, firmware, pool endpoint, timestamps, logs and the calculation used.

Change one variable at a time. Moving pool, firmware, frequency and network route together may restore output but removes the evidence needed to identify the cause. Use a controlled test group and retain a rollback path.

Do not paste pool tokens, wallet credentials or complete network captures into public support channels. Redact secrets while preserving timestamps, error codes and worker identifiers needed for diagnosis.

Frequently asked questions

Which hashrate should I trust?

Use local hashrate for device health and accepted pool hashrate for work delivered to that target. A sound diagnosis uses both with matching intervals.

How long should I compare?

Several hours is a useful first check and a stable twenty-four-hour window is better for sustained performance. Weak miners may need longer because they submit shares less often.

Can variable difficulty change hashrate?

It changes the work represented by each share, not the physical ASIC speed. Incorrectly counting raw shares can nevertheless distort an estimate.

Is a one per cent gap always a fault?

No universal threshold fits every pool, interval and device. Compare the operator’s baseline, reject categories and a sufficiently long period.

Why does the pool show zero while the miner hashes?

Check worker credentials, last accepted share, target URL, proxy route and authorisation responses. Local work is not credited until valid shares reach and are accepted by the target.

Conclusion

Accepted and local hashrate answer different questions. Reconcile them by matching one worker, one unit and one time window, then add share difficulty, reject reasons, uptime and telemetry. Short-window disagreement is often normal variance; a persistent, repeatable gap is an evidence-led diagnostic problem. Keeping raw time-aligned records protects operators, hosts and customers from decisions based on incompatible dashboard figures.

Next steps

Use the fleet-monitoring and troubleshooting guides to build a baseline, then compare candidate miners through sustained pool-side results rather than catalogue hashrate alone.

accepted vs local hashrate should be judged with current evidence, measured operating data and a clearly defined decision.