How to Calculate Bitcoin Mining Revenue: Why Effective Hashrate Matters More Than Nominal Hashrate

Bitcoin mining revenue in 2026 cannot be judged only by a miner’s nominal hashrate or by a one-day revenue screenshot. After Bitcoin’s fourth halving in 2024, the block subsidy fell to 3.125 BTC. Transaction fees change with on-chain demand, and network difficulty keeps adjusting as hashrate competition changes. For miners and site operators, the key question is how much of a machine’s advertised hashrate actually stays online, reaches the pool, produces accepted shares, and generates revenue.

Revenue calculation should start with the network reward pool, then move down to the mining site’s power capacity, miner power efficiency, uptime, pool settlement, and maintenance cost. Operators should model all of these variables together before buying more miners or expanding a site. Otherwise, a single daily revenue figure can create a misleading picture of long-term returns.

Why Mining Revenue Starts with Effective Hashrate

The Bitcoin network produces a block roughly every 10 minutes. Miner income comes from the block subsidy and transaction fees. The block subsidy halves every 210,000 blocks according to protocol rules. Mining uses Proof of Work to support the network’s operating model, and miners receive a probabilistic share of the reward pool according to their hashrate contribution.

A mining rig going online does not mean it will generate a fixed amount of BTC every day. A clearer way to read the model is this: the higher the effective hashrate a miner contributes, the larger its share of the network reward pool; the stronger the network competition, the lower the reward allocated to each unit of hashrate.

Estimated BTC earned ≈ (Miner’s effective hashrate ÷ Network hashrate) × Total network rewards

Effective hashrate must deduct downtime, network latency, rejected share rate, thermal throttling, and maintenance windows. Rated hashrate is useful for an initial estimate, but in real settlement, accepted shares in the pool dashboard, uptime, and settlement rules are closer to the actual revenue result.

How Power Capacity Limits Mining Revenue

The revenue ceiling of a mining site is often determined not by how many rigs can be purchased, but by how much stable power can be supplied continuously. When power capacity is fixed, a lower J/TH converts the same 1 MW of power into more total hashrate. Higher single-unit hashrate does not automatically mean stronger project returns. It becomes meaningful only when compared together with power capacity, cooling capacity, and unit cost.

Theoretical hashrate supported by 1 MW (TH/s) ≈ 1,000,000 W ÷ power efficiency (W/TH)

This means that, without considering auxiliary power consumption, the same 1 MW of power can theoretically release about 14.1 PH/s more hashrate when using a 9.45 J/TH miner rather than a 10.9 J/TH miner.

The table calculates only the power consumption of the mining rigs themselves. It does not include cooling, power distribution, networking, lighting, or other auxiliary loads. In project modeling, PUE or an auxiliary power ratio should be added separately. Otherwise, the nominal 1 MW capacity will overestimate the power that can actually be used by miners.

Track Mining Revenue Across Three Timeframes

Miners often see daily output move up and down, but not every type of volatility has the same meaning. Short-term block discovery and transaction fees are random. Difficulty cycles change revenue per unit of hashrate. Monthly power bills and maintenance records determine whether profit can actually accumulate.

The Bitcoin network adjusts difficulty roughly every 2,016 blocks to bring block production back toward the long-term pace of about 10 minutes per block. Separating short-term volatility, the difficulty cycle, and monthly costs helps avoid mistaking one high-revenue day for long-term operating capability.

How Should Transaction Fees Enter a Conservative Revenue Model?

Transaction fees come from demand for block space. When on-chain transfers are active and block space is tight, users are willing to pay higher fees to get faster confirmation, raising miners’ daily income. When the market is quieter, the fee contribution falls.

A more stable method is to place transaction fees into three scenarios: base, active, and congested. The base scenario is used to judge whether the project can cover power cost and basic operations under ordinary on-chain demand. The active scenario estimates revenue flexibility during normal fluctuations. The congested scenario should be treated only as an upside case and should not be used to cover long-term fixed expenses. In a conservative model, lower or neutral fee assumptions can be used first. Extra income generated during high-fee periods is better treated as profit elasticity, not as the foundation for the payback period.

The block subsidy provides a relatively predictable issuance rhythm, while transaction fees provide variable income. Together, they form the total reward for each block.

How Is Nominal Hashrate Converted into Effective Hashrate?

The hashrate on a miner specification sheet reflects hardware capability. Mining pool settlement is based on effective shares that are actually submitted and accepted. The gap between the two usually comes from uptime, network quality, temperature control, operating mode, and maintenance workflow.

Effective hashrate ≈ Nameplate hashrate × Uptime × Share acceptance rate

Net mining revenue ≈ Gross mining revenue × (1 − Pool fee)

Pool settlement adjustment includes pool fees, settlement method, rejected shares, and differences in statistical standards.

Operating mode changes chip voltage, frequency, and full-machine power consumption. Low-power mode helps control power pressure. High-performance mode is suitable for releasing hashrate over a short period. Normal mode is more suitable for long-term stable operation. The specific choice should be tied to electricity price, ambient temperature, site maintenance capability, and rejected shares in the pool. It should not rely only on instant hashrate.

How to Calculate Mining Cost per PH/s

The revenue side should be recorded in effective PH/s, and the cost side should also be converted to a per-PH basis. This allows different miner models, mining sites, and cooling solutions to be compared in the same table, rather than relying only on single-machine power cost or a rough view of site economics.

Daily cost per PH ≈ (miner power consumption + additional power for distribution and cooling) × 24 × electricity price ÷ effective PH + allocated fixed expenses

High-density mining sites also need a separate evaluation of the cooling route. Hydro cooling affects rack density, maintenance frequency, waste-heat use, and pipeline management. Air cooling relies more on airflow design, filters, ambient temperature, and fan power consumption. For rack-based deployment, equipment size also affects transportation, rack loading, maintenance aisles, and hashrate capacity per unit of space. Therefore, purchasing decisions cannot look only at hashrate and power consumption. A 2U or 3U form factor will continue to influence logistics, rack layout, and hashrate density inside the same space.

Which Table Should Different Types of Miners Focus On?

The same revenue formula has different priorities for different users. Individual miners, hosting customers, and large mining sites can use the same framework, but the order of review should be different.

After a mining site enters an expansion stage, whether new miners can actually generate revenue depends on whether power supply, cooling, racks, network, maintenance, and capital timing are synchronized. If any link cannot keep pace, new nominal hashrate may remain only in a spreadsheet model and may not enter mining pool settlement stably.

Build Your Revenue Model Around Effective Hashrate

Block rewards determine the BTC that the whole network can allocate each day. Difficulty adjustment determines how fast revenue per unit of hashrate changes. Power capacity and power efficiency determine how much energy a mining site can convert into hashrate. Uptime and pool settlement determine how much hashrate finally enters the revenue ledger.

When judging Bitcoin mining revenue, the calculation can proceed in three steps: first, look at the network reward pool and your own effective hashrate share; second, convert power capacity into theoretical PH/s and deduct auxiliary load, downtime, and rejected shares; third, use base-level transaction fees for a conservative model and treat high-fee periods as variable upside.

This financial model cannot remove volatility in BTC price, difficulty, or transaction fees, but it can help miners identify revenue sources, cost pressure, and operational bottlenecks more clearly. When planning miner procurement or mining site expansion, operators can combine Bitdeer SEALMINER A4 series specifications, the mining site’s power contract, and mining pool settlement records to keep updating effective hashrate, unit power consumption, and cost per PH.