MiningViewprofitability
MiningView/Miner's handbook/Stratum, shares and stale work: how an ASIC talks to a mining pool
Pools and payouts·14 min·updated November 14, 2026

Stratum, shares and stale work: how an ASIC talks to a mining pool

An ASIC does not connect to a pool just to receive a wallet address. It continuously receives new work, searches block-header candidates and submits proofs of completed work. Understanding Stratum helps separate normal operation from network, pool or hardware problems.

#Stratum#shares#mining pools#stale shares#ASIC
1 views
Stratum, shares and stale work: how an ASIC talks to a mining pool

An ASIC receives work, not finished coins

A pool creates a job for a miner: data for a current block candidate, target parameters and a search space in which the ASIC can iterate nonce and extraNonce. The chips calculate hashes billions of times per second, while the controller sends results back over the network.

The pool combines the hashrate of many participants and distributes rewards. The ASIC normally does not store a seed phrase or sign payouts: it performs computation, while the pool account and its payout rules determine where the reward goes.

  • a job is the current work assignment
  • nonce and extraNonce expand the search space
  • the ASIC controller maintains the pool connection
  • the payout address belongs in the pool account

A share is not the same as a found block

A share is a result that passes the pool's easier target. It proves that the miner performed part of the work, but almost never qualifies as a network block. The pool collects shares and uses them to calculate the participant's contribution.

Occasionally a share also passes the network target. The pool can then submit the full block to Bitcoin, and the block reward and transaction fees are distributed according to the pool's payout scheme.

  • accepted share means the pool accepted the proof
  • a network block is a rare result below the network target
  • share count is not a direct coin amount
  • PPS, FPPS and PPLNS convert work into payouts differently

Accepted, rejected and stale are different signals

Accepted means the pool accepted the share. Rejected usually points to an invalid format, an old or incorrect job, a result below the required quality or a compatibility problem. A small amount can occur, but a rising reject rate needs investigation.

Stale means the share belongs to an old job. A new block or prevhash may have made the previous work obsolete before the result arrived. A high stale rate often points to latency, unstable DNS, a congested route or a poor pool endpoint.

  • accepted is the normal operating signal
  • rejected means the pool did not accept the result
  • stale means the result arrived after the job changed
  • watch the percentage and trend, not one isolated event

Vardiff changes share difficulty, not ASIC power

A pool can automatically adjust share difficulty for a particular miner. A powerful ASIC receives a harder target and a smaller ASIC receives an easier one, so the pool gets a manageable number of results for accounting. This is variable difficulty, or vardiff.

That is why shares per minute cannot be compared without share difficulty. For operation, look at accepted difficulty, stable hashrate, last-share time and actual payouts.

  • more frequent shares do not automatically mean more income
  • compare work together with share difficulty
  • vardiff can change after connection
  • the first minutes do not show complete statistics

How to diagnose connection problems

If accepted shares exist but stale work keeps rising, start with the nearest pool server, Ethernet cable, DNS and latency. Add backup pool endpoints at lower priority. They do not create extra income by themselves, but they prevent the ASIC from staying idle when the primary endpoint fails.

If the worker is online but five-minute hashrate drops, check the kernel log, temperature, disabled hashboards and power. Separate pool problems from ASIC problems by comparing local hashrate, pool-side hashrate and last accepted share time.

  • add two or three pool endpoints
  • check DNS and latency
  • compare local and pool-side hashrate
  • record outages and stale/rejected events
MetricMeaningWhen to check
AcceptedThe pool accepted the sharePrimary normal-operation signal
RejectedThe pool rejected the shareWhen the rate keeps rising
StaleThe share belongs to an outdated jobDuring latency or reconnects
Last shareTime of the latest accepted resultWhen a worker looks online but is idle
Pool hashrateHashrate estimated from sharesTo compare with the ASIC dashboard

Real photos and source material

These photographs and diagrams are sourced from public archives. Open the source link to check the author and license.

Серверні стійки та мережеві кабелі
Серверні стійки та мережеві кабеліWikimedia Commons · CC BY-SA; умови на сторінці джерела · View source ↗

Want to check the numbers for your ASIC right away?

Open calculator →