Bitcoin Emissions

The Bitcoin Footprint Problem

Bitcoin’s emissions are real, large, and almost universally mis-attributed. The network draws roughly 170.42 TWh [GreenCalculus cryptocurrency.bitcoin.network_annual_consumption · CCAF CBECI 2025 · v2026.203] of electricity per year and emits about 39.8 Mt CO₂e [GreenCalculus cryptocurrency.bitcoin.network_annual_co2e · CCAF CBECI 2025] annually. The methodological difficulty is not measuring that total — it is deciding whose inventory it belongs in and what unit to express it in.

The single most common error is the per-transaction footprint. A widely-cited figure puts one Bitcoin transaction at 488.07 kg CO₂e [GreenCalculus cryptocurrency.bitcoin.tx_emission · DIGICONOMIST BTC]. That number is arithmetically valid — network emissions divided by transaction count — but it implies a causal link that does not exist. Bitcoin’s energy consumption is set by the mining race for block rewards, not by how many transactions a block contains. A block with one transaction and a block with three thousand consume the same energy. Dividing network energy by transaction count produces a number that moves when transaction throughput changes while nothing physical changes at all.

The correct primary unit is the network total — annual TWh and annual Mt CO₂e — because that is the quantity the protocol actually determines. Everything else (per-transaction, per-holding, per-dollar) is an allocation of that total, and the choice of allocation basis is the central methodological decision this page resolves.

Why Proof-of-Work Consumes Energy

Bitcoin secures its ledger by making block production deliberately expensive. Miners race to find a hash below a target threshold; the first to succeed wins the block reward. This is proof-of-work, and three mechanisms make its energy consumption structural rather than incidental.

Hashrate and difficulty

The network’s total computing power — the hashrate — reflects how many miners are competing and how efficient their hardware is. Difficulty adjusts roughly every two weeks to keep block times near ten minutes regardless of hashrate. The consequence is that more efficient hardware does not reduce energy use — it raises the hashrate until the marginal miner is again at break-even. Energy consumption tracks the price of Bitcoin and the cost of electricity, not hardware efficiency, because efficiency gains are competed away.

Mining hardware efficiency

Application-specific integrated circuits (ASICs) have driven hardware efficiency up by orders of magnitude since 2013, but per the mechanism above this lowers energy per hash, not total energy. The MasterBrain carries the network’s representative hardware efficiency and hashrate as live descriptors; both feed the bottom-up consumption estimate in §8.

The security budget

The total reward available to miners — the block subsidy plus transaction fees — is the network’s security budget, and it sets the equilibrium energy spend: miners collectively spend up to the value of the reward chasing it. As the subsidy halves every four years, the long-run energy intensity of the network depends increasingly on fee revenue and on the Bitcoin price. This is why Bitcoin emissions forecasts are price forecasts in disguise.

The Canonical Calculation

Network emissions are annual electricity consumption multiplied by the carbon intensity of the electricity mix that powers mining:

Two estimation chains feed C_annual, reconciled in §8:

• Bottom-up (CBECI / Cambridge): derive a plausible consumption range from observed hashrate and the efficiency profile of the mining hardware fleet, bounded by the economics of mining (a lower bound assuming all miners run the most efficient hardware, an upper bound at break-even electricity cost). The headline is a best-guess within that range.
• Top-down (Digiconomist): assume miners spend a fixed fraction of revenue on electricity at an assumed price, back out energy from miner income. Tends to produce higher estimates; the source of the most-quoted per-transaction figure.

The carbon step then applies I_mining_mix — and this is where geography dominates. The MasterBrain’s representative mining-mix intensity is 0.288 kgCO₂e/kWh [GreenCalculus cryptocurrency.bitcoin.mining_mix_carbon_intensity · CCAF CBECI 2025], materially below a global grid average because a sustainable-energy share of 0.524 [GreenCalculus cryptocurrency.bitcoin.electricity_mix_sustainable_share · CCAF CBECI 2025] of mining runs on hydro, flared gas, and other low-carbon or otherwise-curtailed sources. All cryptocurrency factors carry an AR6 GWP-100 basis (the framework GWP set is recorded in MB at the metadata key cryptocurrency.bitcoin.framework.gwp_set; the boundary at cryptocurrency.bitcoin.framework.boundary).

Network Reference Values

The live MasterBrain descriptors for the Bitcoin network. These render live via [gc_factor] and update with the MasterBrain; the worked examples in §11 hardcode their snapshots for audit-trail integrity.

The per-transaction and per-kWh-of-transaction rows carry a Scope 3 Category 11 tag because they represent a downstream-use allocation; the network descriptors are outside_scopes because a TWh or Mt total is a network property, not an entity’s inventory line. Placing these in an actual inventory is the governance question of §10.

The Per-Transaction Allocation Problem

The per-transaction figure answers “if I divide the network’s emissions evenly across its transactions, what is each transaction’s share?” — a meaningful question for a payment-network comparison, but a misleading one for “what is the marginal cost of my transaction?”, which is approximately zero because the block would have been mined regardless. The three allocation bases:

For corporate and investor reporting, the per-holding basis is the defensible one: it mirrors the PCAF financed-emissions logic of attributing a share of an asset’s emissions to the share of the asset held. An organisation holding Bitcoin on its balance sheet attributes (coins held ÷ circulating supply) × annual network emissions, the same way an equity investor attributes a share of an investee’s emissions. The per-transaction figure has no role in a corporate inventory.

Mining-Mix Carbon Intensity and Geography

The carbon step is where Bitcoin emissions estimates diverge most, because mining is mobile and its grid mix is heterogeneous. The representative mining-mix intensity of 0.288 kgCO₂e/kWh [GreenCalculus cryptocurrency.bitcoin.mining_mix_carbon_intensity] is well below a coal-heavy grid because a substantial share of mining seeks out the cheapest available power — and the cheapest power is often stranded, curtailed, or off-peak renewable generation.

Two methodological consequences follow. First, the mining-mix intensity must be a weighted average over the actual miner geography, refreshed as mining migrates — the post-2021 relocation out of China moved a large share of hashrate to North America and Central Asia, materially changing the mix. Second, the flared-gas and curtailment arguments introduce a baseline-counterfactual question: is mining on flared gas a net reduction (because the methane would otherwise vent or flare) or an addition? This page treats the MB mining-mix intensity as the attributional figure and flags the counterfactual credit as a separate, contested adjustment that must not be silently netted into the headline.

Proof-of-Work vs Proof-of-Stake

The largest single fact in cryptocurrency emissions is that Ethereum’s 2022 transition from proof-of-work to proof-of-stake (the Merge) cut its energy consumption by roughly 99.9%. Proof-of-stake secures the ledger by economic stake rather than computational work, removing the mining race entirely. The MasterBrain carries both Ethereum’s pre- and post-Merge figures and eight proof-of-stake chains, which makes the contrast quantifiable.

All values live from the MasterBrain cryptocurrency family (CCAF/CBECI + CCRI proof-of-stake methods). The proof-of-stake networks consume a fraction of a TWh against Bitcoin’s hundred-plus — the consensus mechanism, not the application, is the determinant of a chain’s footprint. This is the central fact for any organisation choosing which networks to transact on.

The Estimation-Method Debate — Three Positions

Network consumption cannot be metered directly — no one reports miner electricity bills. It is estimated, and three approaches produce materially different headline figures. A Bitcoin emissions figure cannot be interpreted without knowing which produced it.

The reconciliation rule: state the energy basis (A or B) and the carbon basis (C or a flat mix) separately, and disclose both. The MasterBrain headline uses a CBECI-style network total with a representative mining-mix intensity; a corporate user adopting a different basis must say so, because the two can differ by a factor of two.

Attribution and Double-Counting Taxonomy

Six structurally distinct ways a Bitcoin emissions figure misleads. Each is named for citation with a detection signature.

Governance, Scope Placement, and Framework Treatment

The same network emissions land in different inventory lines depending on the entity. Bitcoin emissions are multi-sided: operational for the miner, downstream/financed for the holder, and a portfolio-intensity input for the investor.

Two governance consequences. First, only the miner books Bitcoin electricity as Scope 2 — the miner consumes the power. A holder or investor never books network emissions as Scope 2; they attribute a share as Scope 3, using the per-holding allocation of §5. Mixing these is failure mode F6. Second, because the same network kilowatt-hour is the miner’s Scope 2, the holder’s Scope 3 Cat 11/15, and the investor’s financed emission, Bitcoin emissions are structurally counted multiple times across the economy — correct under GHG Protocol consolidation, but never to be double-counted within one entity’s inventory.

On the disclosure side, the per-holding attribution maps directly onto the PCAF financed-emissions data-quality framework — a treasury holding Bitcoin is, for inventory purposes, financing a share of the network’s emissions. An organisation reporting under CSRD or IFRS S2 with material crypto holdings discloses this share with its attribution basis stated.

Worked Examples — Audit Records

Three audit-record snapshots. All numerics hardcoded for audit-trail integrity — they reconcile to the stated inputs at this page’s review date regardless of future MasterBrain bumps. Snapshot values: network 170.42 TWh/yr and 39.8 Mt CO₂e/yr; mining-mix intensity 0.288 kgCO₂e/kWh; per-transaction 488.07 kgCO₂e.

This reconciles to the live MB per-transaction figure — but it is a ratio, not a marginal cost. The same 39.8 Mt divided by a higher transaction throughput (e.g. via Lightning-network batching or larger blocks) would yield a far lower “per-transaction” number with no change in network energy. Present this only as an average allocation, never as the carbon cost of choosing to transact (failure mode F1).

This is the defensible corporate figure — the financed-emissions logic applied to a Bitcoin holding. It books as Scope 3 Category 15 for an investor or Cat 11 framing for a treasury, with the attribution basis (holding ÷ circulating supply) disclosed. It does not book as the holder’s Scope 2 — the holder consumes no mining electricity (failure mode F6).

The miner uses its own location’s grid factor (grid.<iso3>.electricity.location_based — GB 0.13096 [GreenCalculus grid.gbr.electricity.location_based · DEFRA 2026 'UK electricity'!E25]), not the network mining-mix intensity, because the miner is metering its own consumption. This is a conventional Scope 2 electricity calculation; the network mining-mix figure is for whole-network and holder-attribution purposes only. A market-based miner with a renewable PPA would apply the contractual factor per the renewable-procurement methodology.

Implementation Workflow

Standards Alignment

What the Calculator Handles vs What You Decide

Audit Checklist — Pre-Assurance Pre-Flight

Methodology Metadata — for GHG Inventory Documentation

Version History

Frequently Asked Questions