Blog

A defensible ASIC purchase begins with the datasheet read as a set of rated values under stated test conditions, then validated against site-measured wall power and accepted hashrate. For institutional operators, the ASIC miner specifications that carry real weight are rated hashrate with its stated tolerance, wall power measured at the miner’s own input, efficiency in joules per terahash at a defined inlet temperature, and the electrical and cooling interface the machine demands from the facility. Everything else on a spec sheet supports or qualifies those four numbers.

The gap between rated and observed matters at fleet scale. Bitmain lists the Antminer S21 XP at a typical 270 TH/s and 3,645 W at a 25°C inlet, and notes that actual hashrate may vary by roughly ±3% while wall power and efficiency may vary by roughly ±5%, as summarized in a technical walkthrough of ASIC nameplate data. Applied across a 100 MW deployment, a 5% power variance is not a rounding error. It is a capacity planning decision.

miner-bitcoin.com maintains its ASIC Hardware Intelligence Report for exactly this kind of work: machine-layer records, efficiency analysis, cooling and firmware governance material, and procurement due-diligence frameworks written for investment committees and operations teams. Readers building or auditing a hardware underwriting process are welcome to work through the platform’s hardware intelligence material alongside this framework.

Key Takeaways

• Rated manufacturer figures and site-measured performance are separate data classes and should never be merged in a fleet model.

• Efficiency comparisons only hold when cooling type, operating mode, inlet temperature, and measurement boundary are identical.

• Procurement defensibility comes from an evidence trail tied to serial numbers, revisions, and acceptance tests, not from vendor rankings.

How to Read a Manufacturer Datasheet

A datasheet is a conditional document: every figure on it is valid only under the test conditions printed alongside it. Institutional readers treat the conditions as part of the specification, capture the document version, and record the date the file was retrieved, because manufacturers revise pages without notice.

Which Fields Belong in a Complete Hardware Record?

A hardware record supports procurement, commissioning, and lifecycle decisions only when it carries enough fields to reconstruct a comparison later. At minimum, an institutional record should hold:

• Manufacturer, model, hardware revision, and SKU

• Rated hashrate in TH/s with the stated tolerance band

• Rated wall power in watts and the measurement boundary used

• Rated efficiency in J/TH and the inlet temperature it assumes

• Cooling type: air, hydro, or immersion-rated

• Input voltage range, phase requirement, and maximum current

• Operating temperature and humidity limits, plus any altitude derating

• Physical dimensions, mass, and airflow direction

• Noise rating, with the measurement method if published

• Firmware baseline version and control-board type

• Warranty term, issuer, and exclusions

• Document source URL, version, and retrieval date

Fields left blank should be marked as unpublished rather than estimated. An estimated value entered into a record without a flag becomes indistinguishable from a manufacturer figure within a quarter.

Rated Values, Typical Values, and Operational Measurements

Three distinct data classes appear in fleet models, and merging them produces indefensible forecasts. Rated values are the manufacturer’s stated performance under laboratory conditions. Typical values are the manufacturer’s central estimate with a tolerance band attached. Operational measurements come from the operator’s own instruments at a specific site, firmware version, and ambient condition.

Only the third class describes what a facility will experience. The other two set expectations and define acceptance thresholds. A fleet model that uses rated hashrate for revenue and rated power for cost will overstate margin in both directions at once.

Why Revision Control and Source Dates Matter

Manufacturer specification pages change, and models ship in variants that share a marketing name. The Pro, XP, Hyd and similar suffixes can carry different power supplies, cooling requirements, and operating envelopes, so a quote that names only the family is not a specification.

Practical revision control means archiving the exact PDF or page, recording its retrieval timestamp, and citing that archived copy in the purchase schedule. When a supplier later delivers a different revision, the archived document is the evidence that the delivered unit does not match the approved specification.

Hardware Architecture and Algorithm Boundaries

An ASIC is fixed-function silicon, so the algorithm it was designed for defines the boundary of what it can ever mine. A SHA-256 Bitcoin miner cannot be repointed at Scrypt, RandomX, Equihash, kHeavyHash, Ethash, Etchash, or Blake2b-Sia by changing a pool address, and that hard boundary shapes how hardware risk is assessed.

Why SHA-256 ASIC Design Is Purpose-Built for Bitcoin

Bitcoin’s proof-of-work uses a double SHA-256 computation, and mining ASICs hardwire that logic directly into silicon. There is no instruction decoder, no cache hierarchy, and no programmable routing fabric, which is why purpose-built miners reach efficiency levels that general-purpose processors cannot approach. A detailed account of the ASIC design and tapeout flow describes SHA-256 as a 64-round compression function that designers implement as a fully unrolled pipeline, a partially unrolled design, or an iterative single-round engine, trading silicon area against throughput per watt.

That fixed-function nature carries an underwriting consequence. The machine has no alternative revenue mode if Bitcoin economics deteriorate, so residual value depends on demand for SHA-256 capacity alone.

Chip, Hashboard, Control Board, Power Supply, and Network Interfaces

A mining machine is a small system, and the specification should describe each subsystem separately. The hashboards carry the ASIC dies and their voltage domains. The control board runs firmware, manages the network connection, coordinates the hashboards, and serves the local interface, which is why an explanation of what firmware controls inside a miner frames diagnosis as separating hardware faults from configuration and connectivity faults.

The power supply converts facility AC into the low-voltage, high-current rails the chips need. Mining ASICs run at very low core voltages, in the range of roughly 0.25 to 0.40 V, with correspondingly high current, which makes power integrity a design-critical constraint. Network interfaces and the management plane complete the picture and belong in the electrical and security records, not only the IT inventory.

Why Hashrate Units Cannot Be Compared Across Algorithms

Hashrate units describe work per second within one algorithm and carry no meaning across algorithms. A machine rated in GH/s on SHA-256, one rated in kH/s on Scrypt, one rated in kSol/s on an Equihash variant, and one rated at 1 MH/s on a memory-hard algorithm are measuring different computations with different network difficulty scales.

The practical rule is simple: normalize inside an algorithm, never across one. Dogecoin and Litecoin hardware, for instance, shares the Scrypt family and can be compared internally, but its numbers have no relationship to a Bitcoin machine’s TH/s figure. Cross-algorithm evaluation belongs in a separate framework with its own revenue and residual-value assumptions.

Hashrate: Capacity, Tolerance, and Fleet Planning

Nameplate hashrate is a capacity input, and the number that drives revenue is accepted work reported pool-side over a defined period. The distance between the two is where uptime, rejections, and thermal derating live, and institutional capacity models should carry both figures separately.

Nameplate Hashrate Versus Pool-Side Hashrate

Nameplate hashrate is the manufacturer’s rated output under stated conditions. Pool-side hashrate is a statistical estimate derived from submitted shares over a window, and it reflects what the network credited. Local device readouts sit between them, describing hardware condition without confirming that work reached the pool.

Public operator disclosures show how wide the definitional spread can be. CleanSpark’s unaudited July 2026 update reported 50 EH/s of operational hashrate alongside 38.6 EH/s of average operating hashrate, with 230,507 deployed miners and 808 MW utilized, figures collected in a framework for reading operational hashrate disclosures. The 11.4 EH/s gap between a peak available level and a monthly average answers a different question in each case.

From TH/s to PH/s: Normalizing Unit and Fleet Capacity

Fleet capacity math becomes tractable once every unit is expressed in a single denomination. One PH/s equals 1,000 TH/s, so a fleet of machines rated at 500 TH/s, 580 TH/s, 660 TH/s, 680 TH/s, 865 TH/s, 886 TH/s, and 1.16 PH/s should be converted to a common unit before any aggregation.

Rated capacity sets the machine count and the rack plan. It does not set expected delivered hashrate, which requires the availability and derating assumptions below.

How Uptime, Rejections, and Derating Change Delivered Output

Delivered output is rated capacity multiplied by availability, then reduced by rejected work and by any thermal or firmware derating in effect. Each term needs its own measurement basis and its own review cadence.

Availability covers commissioning delays, repairs, curtailment, and site outages. Rejection rate reflects stale or invalid shares and belongs in pool-side monitoring, since a worker can show as online while its accepted share count declines. Derating covers reduced clock or voltage at elevated inlet temperatures. Operators tracking these terms separately can attribute a capacity shortfall to a specific cause rather than absorbing it into a single fudge factor. Fleet-level tooling such as a bitcoin miner calculator is useful for scenario work provided its outputs are treated as scenarios with dated inputs.

Energy Efficiency and the Meaning of J/TH

J/TH is complete-miner wall power in watts divided by hashrate in TH/s, and because one watt equals one joule per second, the figure reads identically whether written as J/TH or W/TH. Lower values indicate less electrical energy per unit of hashing work under comparable conditions, which makes the measurement boundary as important as the number itself.

Calculating Energy per Terahash From Wall-Power Data

The arithmetic is direct and works in both directions. Efficiency equals wall power in W divided by hashrate in TH/s; wall power equals J/TH multiplied by TH/s; daily energy equals watts divided by 1,000 and multiplied by 24. A worked example using the three efficiency formulas every operator needs puts a machine specified at 580 TH/s and approximately 9.5 J/TH at roughly 5,510 W, or 132.24 kWh per day.

The same analysis shows why marginal efficiency gains scale. At 1 PH/s, a 1 J/TH improvement equals 1,000 W of continuous load, or 24 kWh per day. Across a 10 PH/s fleet at $0.06/kWh, that improvement is about $14.40 per day before site overhead, or roughly $5,256 per year.

Why Power-Supply Losses and Auxiliary Loads Require Separate Treatment

Miner efficiency and facility efficiency answer different questions. Miner efficiency measures the unit at its own input. Facility efficiency measures the energy needed to deliver hashrate from the whole site, including pumps, dry coolers, ventilation fans, transformers, networking, and lighting.

An air-cooled machine carries its fan load inside the wall-power figure. A hydro machine typically does not include the external pump and heat-rejection loads in its rated wall power, which means an unadjusted comparison of a hydro nameplate against an air nameplate flatters the hydro unit. Facility overhead should be modeled as a separate line with its own metering, not folded into a single J/TH figure.

Comparing Efficiency Across Operating Modes and Ambient Conditions

Efficiency comparisons hold only when the compared figures share an operating mode and an inlet condition. Reported drivers of divergence between nameplate and site efficiency include batch variation and manufacturer tolerance, firmware version and selected performance mode, inlet temperature, humidity, dust, altitude and thermal throttling, voltage quality and distribution losses, and fan or pump power.

Model families illustrate how much the mode matters. The Antminer S21, Antminer S21 XP, Bitmain Antminer S21 XP Hyd, Bitmain Antminer S19 XP Hyd, and Bitmain Antminer S19e XP Hyd span multiple generations and cooling architectures, so their published efficiency figures should be read against each machine’s own manual and stated test conditions before any of them enter a shared comparison table. Operator disclosures reinforce the point: a peak fleet efficiency of 16.07 J/TH and an average miner efficiency of 17.9 J/TH describe different measurement bases and are not interchangeable.

Electrical and Facility Interface Requirements

Input voltage, phase, and current are equipment specifications, and they do not by themselves define the circuit, conductor, or breaker a site needs. Those are engineering decisions made by a qualified electrician against continuous-load requirements and local code, using the manufacturer documentation for the exact model and configuration.

Voltage, Phase, and Current Design

The S21 XP’s stated input requirement is 220 to 277 V AC, single phase, at up to 20 A. Hydro models shift the picture: Bitmain’s S21 XP Hyd documentation specifies three-phase electrical input alongside coolant inlet-temperature and flow-rate requirements and operating conditions for an external dry cooler. Those requirements belong to that model and should not be generalized to other liquid-cooled machines.

At fleet scale, three-phase distribution moves more power at lower current per conductor and balances load across circuits more cleanly. Common industrial arrangements include 208 V, 400/415 V, and 480 V three-phase, and a planning guide for mining-farm electrical infrastructure notes that a miner accepting one voltage range or phase configuration may not operate correctly on another even when total capacity looks sufficient. Machines including the Antminer S23, Bitmain Antminer S23 Hyd, Bitmain Antminer S23 Hyd 3U, Bitmain Antminer S23e Hyd 2U, and MicroBT WhatsMiner M79S each carry their own input specification and connector requirement.

Rack Density, Transformer Capacity, and Power-Quality Risk

Rack density is set by the machine’s thermal and electrical envelope, not by shelf space. Continuous loads heat conductors, connectors, busbars, breakers, and PDUs, and the same planning guide reports that many practical designs keep normal circuits and PDUs below roughly 80% of usable rating unless the equipment is specifically rated for continuous full-load operation, subject to verification for the exact equipment and jurisdiction.

Transformer sizing follows total site load, which includes distribution losses and planned spare capacity. Power-quality risk, including voltage variation and harmonic distortion, affects power-supply life and should be measured at commissioning and monitored afterward.

Measuring Miner Load Without Confusing IT Load and Site Load

Miner load is the combined draw of the ASIC units. Site load is total demand at the main service or transformer, adding cooling, ventilation, networking, controls, lighting, and losses. A worked example in the same planning material puts 20 miners at 3.4 kW each at 68 kW of miner load, which grows toward an 88 to 90 kW site requirement once 7 kW of ventilation, 1 kW of networking and controls, and a 15% design margin are included.

Separate metering at both boundaries prevents that distinction from collapsing. Reporting a single site figure as miner efficiency understates machine performance; reporting a single miner figure as site demand understates the electrical build.

Cooling Specifications and Thermal Integration

Cooling type changes the specification baseline, the site interface, and the comparison method, so it is a primary classification field rather than a secondary attribute. Nearly all electrical energy an ASIC consumes is released as heat, and the wall-power figure doubles as a heat-load figure once converted to thermal units.

Air Cooling: Airflow, Filtration, Noise, and Environmental Exposure

Air-cooled specifications hinge on inlet air within the manufacturer’s stated range and a clear exhaust path. The U.S. Department of Energy lists 1 W as 3.412 Btu/h, which places a 3,645 W machine at roughly 12,437 Btu/h of heat rejection and 87.48 kWh per day of energy draw at continuous operation. Recirculation of exhaust into the intake raises inlet temperature and can affect both hashrate and efficiency.

Noise is a siting constraint with a documentation caveat. Bitmain lists the S21 XP at 76 dBA at maximum fan RPM without stating a measurement distance or test-room method, so the figure should not be read as the level experienced at a given distance. The published operating range for that model is −20°C to 45°C, with a reduced maximum temperature at higher altitudes, and that range is a limit rather than a target. Filtration, dust loading, and humidity exposure belong in the environmental record alongside those limits.

Hydro Cooling: Coolant Loops, Heat Rejection, and Manifold Compatibility

Hydro specifications add a fluid interface to the electrical one: coolant inlet temperature, flow rate, pressure limits, fitting and manifold compatibility, and the external heat-rejection equipment. Hydro cooling reduces direct heat discharge into room air, and the underlying heat load remains; it is transported and rejected elsewhere, which introduces coolant-quality, piping, and leak-management requirements.

Machines in this category, including the Bitmain Antminer S23, Bitmain Antminer S23 Hyd, Bitdeer SealMiner A3 Hydro, Bitdeer SealMiner A3 Pro Hydro, Bitdeer SealMiner A4 Ultra Hyd, MicroBT WhatsMiner M66, and MicroBT WhatsMiner M66S, each publish their own loop requirements. Manifold and quick-disconnect compatibility should be confirmed against the specific unit before rack design is finalized.

When Immersion Cooling Changes the Specification Baseline

Immersion cooling replaces the air-side heat path with a dielectric-fluid system, which invalidates air-cooled airflow, fan, and noise specifications for that unit. A technical overview of immersion fluid, flow, and safety requirements frames the tank as one component within a design that also needs verified miner-and-fluid compatibility, circulation, a documented rejection interface, an outdoor or useful-heat sink, plus electrical protection, grounding and bonding, and overcurrent provisions.

Immersion deployment can also void manufacturer warranty terms and changes the machine’s condition history, which affects resale. Both consequences belong in the lifecycle record before the first unit is submerged.

Firmware, Controls, and Configuration Governance

Firmware is privileged software that determines clock, voltage, fan behavior, pool endpoints, and payout-relevant configuration, so it belongs under formal change control. A May 2026 study titled Firmware Distribution as Attack Surface: A Security Study of ASIC Cryptocurrency Miners analyzed 134 publicly distributed firmware images from major vendors and concluded that firmware distribution is a primary attack surface, as summarized in an ASIC security checklist covering firmware and pool accounts.

Firmware Provenance, Signing, and Change Control

Firmware should come from the manufacturer’s official channel or an approved provider with a documented review process, matched to the exact model, hardware revision, and control-board type. Where a checksum, signature, or verification procedure is published, it should be used, and the change record should capture image version, source URL, download date, integrity result, and approving operator.

Fleet-wide updates without a staged test group are the failure mode to design out. A controlled sequence backs up the known-good configuration, preserves the current firmware version, identifies a rollback path, tests a small representative group, then verifies hashrate, temperatures, fan behavior, accepted and rejected shares, pool URL, worker identity, payout destination, and outbound network behavior before expanding in measured batches. Third-party firmware requires separate evaluation of publisher identity, source transparency, signatures, documented developer fees, audit history, warranty implications, and rollback support.

Performance Profiles, Autotuning, and Operating Guardrails

Performance mode is part of the specification, because a machine’s efficiency and wall power depend on the profile it runs. Underclocked, stock, and overclocked profiles produce different J/TH and different thermal loads on the same hardware, which means any recorded measurement is meaningless without the mode attached.

Guardrails define the boundary the fleet may operate within: maximum chip and board temperature, maximum power per unit, permitted voltage range, and fan or pump minimums. Vendor ecosystems differ in what they expose, spanning Antminer hardware from Bitmain, WhatsMiner units from MicroBT, and Canaan Avalon and AvalonMiner products, while open-source devices including Bitaxe, NerdQAxe, NerdMiner, NerdAxe, NerdNOS, NerdOctaxe, and PiAxe are used mainly for development and education at a scale where fleet guardrails do not apply.

Telemetry, Alerts, and Auditability Across a Fleet

Telemetry should establish a documented baseline: normal hashrate, temperature ranges, fan behavior, share acceptance, configured pool URLs, DNS or proxy settings, firmware versions, and payout destinations. Alerting then targets deviations from that baseline rather than absolute thresholds alone.

Auditability requires an asset inventory keyed to serial number, model, control-board type, IP address, owner, firmware version, normal pool endpoint, and physical location, with administrative changes logged. A single device fault is a maintenance item; synchronized configuration changes across many machines warrant faster escalation. Selecting mining software tools that export this data cleanly keeps the audit trail usable across facilities.

Reliability, Repairability, and Lifecycle Cost

Repairability is an economic specification, because parts availability and repair complexity determine whether a failed machine returns to service or becomes salvage. Repair difficulty rises with chip packaging density and generation: older boards have simpler layouts and abundant parts, while current-generation designs carry tighter tolerances and scarcer components.

Failure Domains: Hashboards, Fans, Pumps, PSUs, and Controllers

Failures cluster by subsystem, and each domain carries a different cost and turnaround profile. Published North American price ranges from a repair-cost breakdown by failure type give useful planning anchors, with actual costs varying by shop, region, and circumstance.

Parts availability acts as a hidden cost multiplier. Chips for older models are abundant and cheap, while chips for the newest generation are scarce and expensive when available at all, which can push repair economics into replacement territory regardless of labor rates.

Service Documentation, Spare Parts, and Repair Escalation

A serviceability assessment should run before purchase, not after the first failure. It covers availability of ASIC manuals and service documentation for the exact revision, published error codes, spare-part lead times for hashboards, control boards, PSUs, fans and pumps, and the escalation route from field ASIC troubleshooting to bench-level ASIC repair.

Manufacturer support depth varies across platforms, with Bitmain Antminer hardware carrying the broadest parts ecosystem and other vendors offering thinner supply chains that can extend turnaround. Fleets standardized on a smaller number of models, drawn from families such as the Antminer S21 Pro, MicroBT WhatsMiner M53, M53S, M63, M63S, M63S+, M70, M70S, M70S+, M73, M73S, M73S+, M76, M76S, and M76S+, reduce spare-part variety and technician training load. Having the right diagnostic and service tools on site shortens the interval between fault detection and a repair decision.

Lifecycle Forecasting, Warranty Terms, and Residual-Value Uncertainty

Mechanical life and economic life are separate horizons, and the shorter one governs. A common industry heuristic holds that replacement makes more sense once a repair cost exceeds about 50% of the machine’s current market value, with exceptions where a single dead hashboard still leaves a machine running at partial capacity.

Warranty terms need the issuer identified, because a seller warranty and an original equipment warranty are different promises with different parts access. Residual value carries genuine uncertainty: it depends on secondary-market demand for SHA-256 capacity, condition history including any immersion or overclocking exposure, and remaining warranty. Forecasts should carry stated assumptions, an observation date, and a named owner for updates.

Procurement Due Diligence and Comparative Evidence

Procurement defensibility comes from an evidence trail bound to specific serialized units, with acceptance measures defined before price negotiation. That trail includes the exact hardware revision and power mode, a stated test duration and ambient condition, accepted hashrate instead of a dashboard headline, wall power measured with appropriate instruments, rejected work, temperature and fan and error behavior, and the retained logs.

Institutional underwriting frequently evaluates contemporary platforms such as the Bitmain Antminer S21, MicroBT WhatsMiner M73, and Bitdeer SEALMINER across distinct engineering baselines. Rather than ranking units by headline metrics, defensible due diligence requires auditing each architecture’s specific power-delivery limits, cooling dependencies, and supply-chain track record.

How to Verify Model Identity, Configuration, and Delivery Scope

Model identity verification starts with a graded view of the evidence. Guidance in a supply-chain and procurement risk framework separates controlling item-specific records such as executed contracts and serialized inspections from seller-controlled material like quotes, listings, dashboards and seller-run tests, and treats unsupported aggregates including market-share estimates and popularity rankings as unusable for approval.

The purchase schedule should name quantity, exact model, hardware revision, serial or serial-allocation process, power supply, cables and accessories, packaging standard, permitted firmware baseline, new or used or refurbished status, cosmetic grade, prior service history, and excluded damage. Terms including “new,” “unused,” “refurbished,” “tested,” and “as is” have no universal technical meaning and require definition inside the contract.

Comparing SHA-256 Machines on an Infrastructure-Adjusted Basis

Comparing SHA-256 machines fairly means adjusting for what each one demands from the site. Two machines with similar J/TH ratings can require different electrical services, different heat-rejection equipment, and different rack designs, so a capacity-normalized comparison should carry cost of electrical build, cooling infrastructure, installation, maintenance, and water treatment where applicable.

A structured comparison holds cooling type, operating mode, and inlet condition constant, then layers site overhead on top. Hydro and air platforms including the Bitmain Antminer S23, Bitmain Antminer S21, Bitdeer SealMiner, Bitdeer SealMiner A2 Air, A2 Hydro, A2 Pro Air, A2 Pro Hydro, A3 Air, and A3 Pro Air belong in the same table only once those adjustments are explicit. Vendor breadth across Bitmain, MicroBT, Bitdeer, Innosilicon, and Goldshell also affects parts access and firmware governance, which are procurement criteria in their own right.

How to Treat Non-SHA-256 Hardware in a Separate Evaluation Framework

Non-SHA-256 hardware requires its own framework because its revenue, liquidity, and residual-value dynamics differ from Bitcoin machines. Units such as the Antminer X5, Bitmain Antminer X9, Antminer Z15, Antminer Z15 Pro, Bitmain Antminer Z15, and Bitmain Antminer Z15 Pro target other algorithms, and their hashrate units carry no comparability to TH/s.

Scale differences reinforce the separation. A 52.5 GH/s rating on one algorithm and a 580 TH/s rating on SHA-256 are not points on a shared axis. Any portfolio holding both should model them as distinct asset classes with separate difficulty, market-depth, and support assumptions.

Turning Hardware Data Into Defensible Fleet Decisions

Institutional evaluation of ASIC miners holds three data classes apart: manufacturer rated values with their stated tolerances, site-measured performance under recorded conditions, and modeled forecasts with dated assumptions. Mining hardware records that carry model, revision, firmware baseline, cooling type, electrical interface, and document retrieval dates make later comparisons reconstructible.

Hashrate sets capacity and J/TH sets energy intensity, and neither figure means much without its measurement boundary, operating mode, and inlet condition attached. Facility overhead, repair economics, parts availability, and residual-value uncertainty complete the picture that a specification sheet alone cannot provide. For Bitcoin operations, the practical output is a hardware record and an acceptance protocol detailed enough that a procurement decision can be audited a year later against the evidence that supported it.

Frequently Asked Questions

Which ASIC miner specifications matter most to institutional operators?

Rated hashrate with its tolerance band, wall power measured at the miner input, efficiency in J/TH at a stated inlet temperature, and the electrical and cooling interface requirements carry the most weight. Serviceability fields such as parts availability, warranty issuer, and firmware baseline belong in the same record because they drive lifecycle cost.

How should J/TH be calculated and validated?

Divide complete-miner wall power in watts by hashrate in TH/s, since one watt equals one joule per second. Validation requires measuring both terms at the site under a recorded firmware version, performance mode, input voltage, and inlet temperature, then comparing that result against the manufacturer figure and its stated tolerance.

What is the difference between manufacturer hashrate and observed hashrate?

Manufacturer hashrate is a rated or typical value produced under laboratory test conditions with a tolerance band attached. Observed hashrate is what a site delivers over a defined period after availability losses, rejected shares, and thermal or firmware derating, and it is the figure that corresponds to credited work.

How do hydro-cooled and air-cooled ASIC specifications differ?

Air-cooled specifications center on airflow, inlet temperature range, and a fan load included in the rated wall power. Hydro specifications add coolant inlet temperature, flow rate, manifold compatibility, and external heat-rejection equipment, and their pump and dry-cooler loads usually sit outside the machine’s rated wall power.

What should a procurement team verify before purchasing ASIC miners?

Verify the legal seller entity and payee, the exact model and hardware revision bound to serial numbers, the defined condition terms, allocation of shipping and import risk in writing, and a documented right to inspect, test, reject, and recover. Acceptance measures and tolerances should be agreed before price negotiation.

How often should ASIC hardware specifications and fleet assumptions be reviewed?

Specification documents should be re-retrieved and version-checked before each procurement cycle, since manufacturers revise pages without notice. Fleet assumptions covering availability, derating, repair rates, power cost, and residual value warrant review at least quarterly, with every volatile input carrying an observation date and a named owner.