Definition
A share is a proof-of-work solution that satisfies a lower difficulty target set by a mining pool, rather than the full Bitcoin network difficulty. Most shares will never be valid blocks, but they are accounting tokens: they prove a worker is genuinely hashing, and the pool counts them to distribute rewards fairly when one member eventually finds a real block.
Also known as: pool share, work share.
How a share is produced and validated
Every share is just a candidate block header that hashes below a target. The pool dictates that target through the Stratum protocol. In Stratum V1, the pool sends mining.set_difficulty followed by a mining.notify work template (job ID, previous-block hash, coinbase parts, merkle branches, version, nBits, nTime, and a clean-jobs flag). Your ASIC iterates the nonce field (and, with version-rolling enabled, a slice of the version field) until it produces a header hash at or below the share target.
The relationship between the pool’s stated difficulty and the underlying hash target is precise: target = 2^256 / (65536 × difficulty). A higher share difficulty means a smaller target, so candidate hashes must clear a tougher bar before they qualify as shares. When a match is found, the miner submits it with mining.submit, sending the worker name, job ID, extranonce2, nTime, and nonce back to the pool.
Before a well-behaved firmware even transmits a share, it validates the solution locally to avoid wasting bandwidth: confirm the job ID is still active, reconstruct the full block header (version + previous hash + merkle root + nTime + nBits + nonce), double-SHA256 it, and check that the result is less than or equal to the target derived from the current difficulty. If ASICBoost version-rolling is in use, the rolled version bits must stay inside the mask the pool negotiated. The pool then re-validates the same way before crediting the share.
Why shares matter for real ASIC mining
Share difficulty is a tuning knob, not a fixed value. Set it too low and a fast machine floods the pool with submissions, burning network overhead on both ends. Set it too high and a small miner — a single Bitaxe, say — submits so rarely that the pool gets a noisy, unreliable picture of its true hashrate. Many pools therefore use variable difficulty (vardiff), ratcheting the target up or down per connection so each worker lands on a steady cadence of shares. The achieved difficulty of submitted shares is also how dashboards estimate a machine’s real hashrate, since you cannot see individual hashes — only the shares that clear the bar.
On the production floor, the share counter is your single best health signal. A healthy machine produces a stable stream of accepted shares. Two failure modes show up immediately in the share log:
- Rejected shares — the pool refused the submission (bad job, low difficulty, malformed header, or version bits outside the negotiated mask). A sudden spike in reject rate is a classic symptom of a misconfigured pool connection, a flaky hashboard, or an overheating chip producing hardware errors.
- Stale shares — the share was valid for a job the pool has since abandoned. When a new block is found, the pool issues a fresh template with the clean-jobs flag set; any share still chasing the old job arrives too late and is discarded. High latency, weak Wi-Fi, or a saturated control board all push stale rates up.
Persistent share rejects are serious enough that resilient firmware treats them as a failover trigger: after several consecutive rejects, a robust stratum client will cut over to a backup pool rather than keep grinding into a dead connection. If your shares dry up entirely, the problem is rarely the chips — it is almost always the network path, the pool credentials, or a thermal/power fault that has knocked a hashboard offline.
Shares and getting paid
Shares are the unit of accounting behind every pooled-mining reward scheme. Under proportional and PPLNS-style models, the pool tallies each worker’s accepted shares and pays out a slice of the block reward in line with the work contributed during the relevant window — which is exactly why a few percent of rejects or stales eats directly into revenue. In a solo-pool setup, shares still flow to prove liveness, but only an actual block-finding share earns the full reward. Either way, watching accepted-versus-rejected share ratios is the most direct way to catch a problem before it costs you sats.
If you are sizing or troubleshooting a rig, treat the share log as the ground truth: a clean, steady share stream means hardware, firmware, and pool connection are all cooperating. Browse the ASIC miner catalogue to match a machine to your power and hashrate goals, and if your share counts look wrong, our ASIC troubleshooting hub walks through the network, thermal, and hashboard checks in order.
Related terms: Mining Pool, Stratum Protocol, Difficulty, Nonce, PPLNS.
In Simple Terms
A partial proof of work submitted to a pool to prove your miner is working. Used to calculate your reward share.
A share is a proof-of-work solution that satisfies a lower difficulty target set by a mining pool, rather than the full Bitcoin network difficulty. Most shares will never be valid blocks, but they are accounting tokens: they prove a worker is genuinely hashing, and the pool counts them to distribute rewards fairly when one member eventually finds a real block.
Also known as: pool share, work share.
How a share is produced and validated
Every share is just a candidate block header that hashes below a target. The pool dictates that target through the Stratum protocol. In Stratum V1, the pool sends mining.set_difficulty followed by a mining.notify work template (job ID, previous-block hash, coinbase parts, merkle branches, version, nBits, nTime, and a clean-jobs flag). Your ASIC iterates the nonce field (and, with version-rolling enabled, a slice of the version field) until it produces a header hash at or below the share target.
The relationship between the pool's stated difficulty and the underlying hash target is precise: target = 2^256 / (65536 × difficulty). A higher share difficulty means a smaller target, so candidate hashes must clear a tougher bar before they qualify as shares. When a match is found, the miner submits it with mining.submit, sending the worker name, job ID, extranonce2, nTime, and nonce back to the pool.
Before a well-behaved firmware even transmits a share, it validates the solution locally to avoid wasting bandwidth: confirm the job ID is still active, reconstruct the full block header (version + previous hash + merkle root + nTime + nBits + nonce), double-SHA256 it, and check that the result is less than or equal to the target derived from the current difficulty. If ASICBoost version-rolling is in use, the rolled version bits must stay inside the mask the pool negotiated. The pool then re-validates the same way before crediting the share.
Why shares matter for real ASIC mining
Share difficulty is a tuning knob, not a fixed value. Set it too low and a fast machine floods the pool with submissions, burning network overhead on both ends. Set it too high and a small miner — a single Bitaxe, say — submits so rarely that the pool gets a noisy, unreliable picture of its true hashrate. Many pools therefore use variable difficulty (vardiff), ratcheting the target up or down per connection so each worker lands on a steady cadence of shares. The achieved difficulty of submitted shares is also how dashboards estimate a machine's real hashrate, since you cannot see individual hashes — only the shares that clear the bar.
On the production floor, the share counter is your single best health signal. A healthy machine produces a stable stream of accepted shares. Two failure modes show up immediately in the share log:
- Rejected shares — the pool refused the submission (bad job, low difficulty, malformed header, or version bits outside the negotiated mask). A sudden spike in reject rate is a classic symptom of a misconfigured pool connection, a flaky hashboard, or an overheating chip producing hardware errors.
- Stale shares — the share was valid for a job the pool has since abandoned. When a new block is found, the pool issues a fresh template with the clean-jobs flag set; any share still chasing the old job arrives too late and is discarded. High latency, weak Wi-Fi, or a saturated control board all push stale rates up.
Persistent share rejects are serious enough that resilient firmware treats them as a failover trigger: after several consecutive rejects, a robust stratum client will cut over to a backup pool rather than keep grinding into a dead connection. If your shares dry up entirely, the problem is rarely the chips — it is almost always the network path, the pool credentials, or a thermal/power fault that has knocked a hashboard offline.
Shares and getting paid
Shares are the unit of accounting behind every pooled-mining reward scheme. Under proportional and PPLNS-style models, the pool tallies each worker's accepted shares and pays out a slice of the block reward in line with the work contributed during the relevant window — which is exactly why a few percent of rejects or stales eats directly into revenue. In a solo-pool setup, shares still flow to prove liveness, but only an actual block-finding share earns the full reward. Either way, watching accepted-versus-rejected share ratios is the most direct way to catch a problem before it costs you sats.
If you are sizing or troubleshooting a rig, treat the share log as the ground truth: a clean, steady share stream means hardware, firmware, and pool connection are all cooperating. Browse the ASIC miner catalogue to match a machine to your power and hashrate goals, and if your share counts look wrong, our ASIC troubleshooting hub walks through the network, thermal, and hashboard checks in order.
Related terms: Mining Pool, Stratum Protocol, Difficulty, Nonce, PPLNS.