VNISH GLOBAL · Academy
How an ASIC Mining Stack Works: Hash, Share, Pool and Firmware
An ASIC receives work from a pool, builds candidate header data and repeatedly evaluates SHA-256. A result below the pool target is a share; only the much rarer result below the network target can become a block. Firmware coordinates the local device, while the pool, Bitcoin consensus and the electrical installation remain separate systems.
Working method
- Separate the layers: Bitcoin consensus defines valid blocks; the pool packages work and accounts for shares; the miner performs hashing; firmware schedules chips, cooling and telemetry.
- Read local hashrate, pool-side hashrate and accepted shares as different observations with different windows. A single dashboard value cannot replace all three.
- Use wall power and a matching hashrate window for efficiency. Record source, unit, timestamp, profile and ambient conditions so another operator can reproduce the calculation.
- Treat a share as evidence of work against the pool target, not automatically as a found block or a payout amount. Pool payout rules are a separate contract.
Work through a situation
Learning scenario - not a reported customer result.
Consider a hypothetical operator who sees a steady hashrate in the miner interface but a different number in the pool account. Neither screen, on its own, establishes which component is responsible for the difference. Start by writing down what each number describes: the named device, the source, the unit and the observation period.
A short local window and a longer pool window are not a like-for-like comparison. Next, distinguish an accepted share from a payment. The share records work that met the pool's requirements; the account's payout rules determine how credited work becomes a balance.
Now consider a second observation: the interface remains reachable, but the intended worker has no new accepted work in the period being reviewed. That is a reason to preserve the pool state and relevant logs, not to declare the installation successful from the login screen. Keep the firmware version and profile attached to the record.
This small comparison can narrow the next question without guessing a fault, changing a setting or promising extra revenue.
Limits and stop conditions
- Firmware cannot remove PSU, wiring, cooling or silicon limits.
- A local UI value does not prove pool acceptance; a pool value does not identify the local cause of a fault.
- Never transfer limits or settings between Air, Hydro and Immersion variants without an exact route record.
Reusable artifact
| # | Field | Checked | Evidence / note |
|---|---|---|---|
| 1 | Job source and observation window | □ | |
| 2 | Local hashrate and its source | □ | |
| 3 | Pool-side hashrate and accepted/rejected/stale categories | □ | |
| 4 | Wall power, meter and timestamp | □ | |
| 5 | Exact model, board, build and profile | □ |
Copy this structure into a change record; never place passwords, keys or private access details in it.
Terms used in this guide
- Share
- Work submitted to a pool for validation against the pool's target; most shares are not valid network blocks.
- Observation window
- The stated period covered by a measurement or record.
- Pool-side hashrate
- A pool's estimate of mining work over its stated observation period, not a direct reading of local chip activity.
Check your understanding
These questions check understanding. They do not approve an installation or certify a result.
Can two hashrate numbers be compared without checking their periods?
Show answer
No. Record both sources, units and periods before interpreting a difference.
Does an accepted share prove that a payout has arrived?
Show answer
No. Share acceptance and the pool's payout accounting are separate observations.
What does a reachable interface prove?
Show answer
Only that the interface responds; it does not prove accepted mining work or stable operation.
Primary sources
- Bitcoin Developer Guide - Mining Reviewed 2026-09-10
- Stratum V2 - Mining Protocol Reviewed 2026-09-10