Is the entire Bitcoin block reward mining revenue, and when is it recognised?

Not automatically. The coinbase output contains a protocol subsidy and transaction-fee rewards, and the treatment depends on whether the entity is a solo miner, pool participant or operator, and on the revenue model that applies.

When should a pool participant recognise it?

It depends on the contract, the performance obligation and the payout method. Private pool records can support recognition before the wallet payout, and the payout may only settle a receivable. The 100-block maturity rule does not decide it: that is a spending restriction protecting against a block later being found stale. ASIC hardware, separately, is property, plant and equipment when the recognition criteria are met, not Bitcoin inventory.

Can electricity be capitalised into mined Bitcoin?

Under IFRS, eligible production costs can enter IAS 2 inventory where the facts support a production model, subject to the IAS 2.16 exclusions and IAS 2.13 normal-capacity rule; under a service model they are expenses of providing the service. The same cost cannot be both, and US GAAP offers no comprehensive mining-cost model.

Is KPMG's 2026 mining guidance authoritative, and does an SEC comment letter bind my client?

No, on both counts. KPMG's handbooks are major-firm interpretation, usable under IAS 8.12 and the ASC 105 hierarchy only after authoritative sources are exhausted. A comment letter is staff correspondence with one registrant about that registrant's own facts: strong evidence of how the staff reads a requirement (the ASC 606-10-32-21 point being a good example) but not codified GAAP, and a non-SEC registrant is not subject to it. The IFRS Standards and the FASB Codification remain authoritative.

Bitcoin Mining Accounting: Rewards, Pools, Revenue, ASICs and Costs

Bitcoin mining accounting starts with one receipt that hides two different incomes. At block height 840,000 the protocol paid out a single output worth 40.75061499 BTC. Only 3.125 BTC of that was newly issued currency; the other 37.62561499 BTC was transaction fees paid by the people whose payments went into the block.

That was about twelve times the subsidy, in a deliberately extreme block, since ordinarily fees are a small fraction of it (mempool.space, corroborated on Blockstream). One receipt, two economically different sources of income, and no standard saying what to credit.

That is Bitcoin mining accounting in miniature, and the word mining hides three businesses. A solo miner wins a protocol reward directly, with no obvious counterparty for the subsidy. A mining-pool participant sells computing work to an operator under a contract and can earn a balance in the pool's private records days before any bitcoin (the asset; ticker BTC) reaches its wallet. A pool operator coordinates participants, receives the reward, owes them their shares and earns a fee.

Scope. This is financial reporting by an entity under IFRS Accounting Standards or US GAAP, not tax. Mining tax differs sharply by country and by whether the miner is an individual or a company: see Canada, the United States, the United Kingdom and the European Union.

Mining revenue is not one homogeneous number

Protocol mechanics, pool contracts and accounting recognition are three separate questions.

Proof of workThe block reward combines a fixed subsidy and variable transaction fees.
Solo or pool modelPPS, FPPS and success-based pools create different contractual entitlements.
Entitlement or receivableRevenue may arise in the pool's private ledger before any BTC arrives.
BTC payoutReceipt is a settlement event, not necessarily the recognition event.

The cost and presentation questions

ASIC hardwareProperty, plant and equipment
Electricity and hostingOperating cost or cost of production
Gross versus netPrincipal or agent analysis
Noncash considerationMeasurement date differs by framework

Neither IFRS nor US GAAP supplies a complete mining model. Separate explicit standards from interpretation and document the judgement.

Start with the protocol: what does a Bitcoin miner actually receive?

Miners assemble valid transactions into candidate blocks and perform proof of work, repeatedly hashing block-header data on purpose-built machines until a result falls below the network's target. A hash is an unpredictable fixed-length fingerprint of data, so the only way to find one below a threshold is to keep trying, though every other node verifies the answer instantly.

The miner whose block the network accepts includes a special first transaction, the coinbase transaction (no relation to the company Coinbase). It has exactly one input, whose previous outpoint is null, so it is not funded by spending an earlier output (developer reference). It creates BTC and simultaneously collects the difference between total inputs and outputs across every other transaction in the block. The Bitcoin Developer Guide calls that the block reward, "comprised of a block subsidy and any transaction fees paid by transactions included in this block" (developer.bitcoin.org). Two components, one output, two different analyses, so the subledger must keep them apart even though the wallet sees one receipt.

The block subsidy is programmed, the transaction fees are not

Bitcoin Core halves the subsidy on a fixed schedule: "Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years" (Bitcoin Core source). At block 840,000 it fell to 3.125 BTC, and the audited 2025 Form 10-K of MARA Holdings, Inc. (formerly Marathon Digital Holdings), a US-listed miner cited throughout as filed evidence, confirms that "[a]fter the halving event of April 2024, the current reward for each solved block is equal to 3.125 bitcoin plus transaction fees" (sec.gov). The subsidy is forecastable years ahead. Fees are not: they depend on transaction demand, the rates users bid and what the miner includes. So "block reward" must never be treated as one homogeneous number.

Store the subsidy and the fee reward separately even though the protocol pays them together.

Coinbase maturity is a spending restriction, not a policy election

Bitcoin Core sets COINBASE_MATURITY = 100 (consensus.h): a coinbase output cannot be spent until 100 further blocks are built on top. The protocol's own reason matters, because the delay "temporarily prevents a miner from spending the transaction fees and block reward from a block that may later be determined to be stale (and therefore the coinbase transaction destroyed) after a block chain fork" (developer.bitcoin.org). The rule is evidence about the risk that a block leaves the accepted chain.

That is useful evidence. It is not a rule that revenue is recognised only after 100 blocks, nor that the asset does not exist until then, nor a licence to pick any confirmation count as an accounting date. Validation, active-chain acceptance, confirmations and maturity answer different questions. They are not a menu of dates.

Solo mining and pool mining are not the same transaction

A solo miner does the work itself and, if its block wins, receives the subsidy and fee reward directly. A pool participant does something quite different: it sells computational work to an operator under a contract. The pool sets a target "a few orders of magnitude higher (less difficult) than the network difficulty," and measures the participant by what it returns: "the information the miner sends to the pool is called a share because it proves the miner did a share of the work" (developer.bitcoin.org).

Shares are not Bitcoin transactions. They exist only in the pool's private system, so the evidence differs fundamentally. A solo miner evidences the reward with node and candidate-block data, the coinbase transaction, active-chain status and the split between subsidy and fees. A participant evidences it with the pool contract, accepted-share history, the payout method and fee schedule, its private pool balance and payout threshold, and only then a settlement on the Bitcoin chain or over the Lightning Network (a layer that settles between two parties without recording each payment on the chain).

The chain shows that final payout and nothing behind it. MARA reports that it relies on daily pool reports, "depend[s] on the accuracy of each such pool's recordkeeping," and has "minimal recourse against external pool operators" if its proportion looks wrong (sec.gov). For a participant the pool's private ledger is the accounting record, not a supporting schedule.

PPS, FPPS and success-based pools create different entitlements

Pools convert shares into an entitlement through a payout method. It is not a marketing label: it changes what the participant is owed and when the amount becomes estimable, and the SEC staff has told a registrant to "ensure your disclosure articulates the difference between PPS and FPPS payout methodologies" (SEC comment letter, 2 Feb 2024).

Pay-per-share (PPS). A guaranteed payment for every valid share regardless of whether the pool finds a block, built from the subsidy only: MARA describes PPS pools as paying "block rewards less mining pool fees but no transaction fees" (sec.gov). The operator absorbs the luck.

Full-pay-per-share (FPPS). The same guarantee, but built from the subsidy and an estimated fee component: "block rewards and transaction fees, less mining pool fees," in the same filing. Under both, the entity "is entitled to non-cash consideration even if a block is not successfully validated by the mining pool operators."

Success-based. Paid only out of blocks the pool actually wins (a fractional share "reduced by pool operator expenses only if a block is successfully validated"), so amounts can stay genuinely uncertain until the condition is met.

The payout method therefore drives when consideration becomes estimable or ceases to be constrained, not merely how much arrives, and under PPS and FPPS the entitlement exists whether or not the pool wins a block.

Earning and payout are two events, not one

Suppose a participant's pool account shows 0.05 BTC earned, and three days later the pool sends 0.05 BTC to its wallet. One operator calls that internal balance a "Financial Account … a place where your mining rewards are stored once confirmed" (Braiins), one pool's design, not a universal rule. If the amount became revenue with a receivable when it was enforceable and measurable, the later transfer settles that receivable:

At accrual   Dr Pool receivable / earned balance   Cr Mining revenue
At payout    Dr Bitcoin asset                      Cr Pool receivable / earned balance

Booking revenue at both moments doubles income. A wallet-receipt feed on its own does something different but equally wrong: it misdates the revenue to the payout. Loading the pool ledger alongside it is what creates the double count, unless each payout is mapped to settlement of the receivable rather than to revenue.

IFRS: the 2019 holdings decision does not reach mining

The IFRS Interpretations Committee (the body answering application questions on IFRS Accounting Standards) concluded in its June 2019 agenda decision that a qualifying cryptocurrency holding falls under IAS 2 Inventories when held for sale in the ordinary course of business, and otherwise under IAS 38 Intangible Assets. That classifies an asset the entity already has. It says nothing about when a miner recognises a reward, or what it credits.

So the miner must analyse how the BTC was earned first. KPMG's June 2026 IFRS analysis addresses mining and pools directly and is candid about the limits: "[j]udgement is required to determine whether the protocols set out in the blockchain operating arrangements give rise to a contract with a customer" (kpmg.com). It is a firm's interpretation, not authority.

IFRS pool participant: IFRS 15 where the operator is a customer

Where an enforceable pool agreement identifies the operator as a customer receiving a specified hashing or validation service, IFRS 15 can apply, and the participant works the five-step model rather than treating the receipt as revenue.

What is the promised service?

Usually the continuous provision of computational power, but the contract decides, and regulators care about the precision. The SEC staff told MARA that "to provide computing power" was "too general to distinguish whether you provide a good or service," and asked it to clarify, if true, that in pools it does not operate it "provide[s] a service of performing hash calculations for pool operators" (SEC comment letter).

When is the obligation satisfied, and how much is constrained?

A service can transfer over time as computing power is supplied, or the facts may support another pattern; either way it turns on when the customer obtains control, not on when BTC lands. PPS and FPPS amounts can often be estimated before a block succeeds; success-based amounts usually cannot. One qualifier is easy to lose: under IFRS 15.68, variability arising from the form of the consideration (the BTC price itself) is outside the constraint. Only variability from other causes, such as block success, is constrained.

How is noncash consideration measured?

IFRS 15.66 requires the BTC reward to be measured at fair value, but IFRS 15 prescribes no measurement date. Contract inception, receipt and satisfaction of the performance obligation are all arguable, so the entity must adopt a measurement-date policy fitting its facts, develop it through the IFRS hierarchy and disclose it. This is a real divergence from US GAAP, one of the few places where two otherwise identical mining ledgers differ by construction.

Is the retained pool fee contra-revenue, expense or neither?

If the operator is the customer and retains part of the consideration, IFRS 15's consideration-payable-to-a-customer requirements apply, and the answer differs again if that amount buys a distinct service. Test a third possibility first: where the contract defines the entitlement net, as in FPPS pools paying "block rewards and transaction fees, less mining pool fees" (sec.gov), the deduction may be part of determining the transaction price rather than a payment to a customer.

Bitcoin mining accounting for solo miners under IFRS: the customer problem and the IAS 8 hierarchy

Solo mining is harder: a decentralised network is not readily an identifiable customer with an enforceable contract, which makes IFRS 15 difficult to apply to the subsidy at all.

Where no IFRS Standard specifically applies, IAS 8 requires management to develop a relevant and reliable policy (IAS 8.10). IAS 8.11 says management shall refer, in descending order, to IFRSs dealing with similar and related issues and then to the Conceptual Framework; IAS 8.12 says it may also consider other standard-setters' pronouncements, other accounting literature and accepted industry practice, but only "to the extent that these do not conflict with the sources in paragraph 11." That permissive tier is what makes firm interpretation usable at all, and it ranks below the standards rather than beside them. The protocol facts (validation, active-chain acceptance, reorganisation risk, confirmations, maturity) are evidence applied to the recognition criteria, and the entity must document why its policy best reflects when an asset and its credit arise.

What happens to mined BTC after recognition?

Once recognised, the holding is classified separately from the revenue analysis: the 2019 decision routes it to IAS 2 if held for sale in the ordinary course of business and to IAS 38 otherwise, while under US GAAP an in-scope holding enters ASC 350-60 fair-value accounting. Mining does not make every holding broker-trader inventory, and later sales, supplier payments, lending and losses are separate asset events.

One presentation trap follows. IAS 38.113 measures the gain or loss on derecognition as net disposal proceeds less carrying amount and recognises it in profit or loss, but adds that "[g]ains shall not be classified as revenue," so a gain on selling mined BTC held under IAS 38 does not belong on the revenue line, even for an entity whose whole business is mining.

US GAAP: ASC 350-60 deliberately does not solve initial recognition

ASC 350-60, introduced by ASU 2023-08, changed US GAAP dramatically for qualifying crypto assets by requiring subsequent measurement at fair value with all changes in net income (ASC 350-60-35-1). It stops there, and says so: ASC 350-60-05-2 states that the Subtopic "does not address the initial measurement, recognition, and derecognition of crypto assets," which follow "other generally accepted accounting principles." So it does not answer the first mining question at all:

When, and against what credit, does the miner recognise the BTC reward?

Where a contract with a customer exists, Topic 606 can apply. Otherwise ASC 105-10-05-2 requires the entity to "first consider accounting principles for similar transactions or events within a source of authoritative GAAP" before turning to nonauthoritative sources (FASB Codification; the paragraph appears verbatim in ASU 2009-01). The KPMG US Crypto Assets Handbook, April 2026 is nonauthoritative interpretation of what that produces in practice.

US GAAP pool participant: Topic 606 and the contract-inception trap

KPMG's April 2026 interpretation works the model on a stated assumption: that the operator is the principal in providing validation services to the network or requester and so meets the definition of a customer. On that assumption "the nature of the pool participant's performance obligation is a single service of providing computational power to the pool operator," and "rewards revenue is earned as the computational power is provided to the pool," generally recognised the same day (kpmg.com). Change the assumption and the answer changes. Contract term is the first practical problem: pool arrangements typically let either party terminate at any time without penalty, so the contract does not extend beyond the cancellable period, "an evergreen contract that continuously renews throughout each day," in KPMG's words.

Then comes the measurement date, where Bitcoin mining accounting most often goes wrong. ASC 606-10-32-21 requires noncash consideration to be measured at estimated fair value at contract inception, materially more specific than IFRS 15, which fixes no date. Measuring a success-based reward at the price when the block was won is intuitive, and the SEC staff has rejected it in writing: it "does not comply with the requirement in ASC 606-10-32-21 to measure noncash consideration at contract inception," the staff wrote of measuring "using the spot rate of bitcoin at the time that the block is successfully mined," requiring one approach applied consistently across all participant contracts and a materiality analysis of the correction (SEC comment letter).

Keep the two questions apart: the constraint governs when revenue can be recognised, ASC 606-10-32-21 governs which date prices it, and lifting a constraint does not reset the measurement date. For continuously renewing contracts KPMG reports two observed conventions (a consistent time-of-day spot price, or a simple average daily spot price for each day of service), either of which "may be acceptable depending on the terms of the specific mining pool arrangement." Interpretation applied to contract facts, not a universal pricing rule.

US GAAP solo miner: no comprehensive model

A solo miner meets the same customer problem. The SEC staff has objected, in correspondence with one registrant, to a specific presentation: "[r]evise the table so that 'Operator - block reward' revenue is not characterized as revenue from contracts with customers" (SEC comment letter), staff comment to one issuer on its own facts, marking a boundary rather than binding every miner.

Where there is no customer and no applicable Topic, the ASC 105 hierarchy applies and the entity develops a consistent policy, using authoritative analogy before nonauthoritative literature. KPMG's April 2026 view is that where Topic 606 is applied by analogy to a solo miner, "[c]ontract inception and the satisfaction of the miner's performance obligation generally occur simultaneously," at successful validation (kpmg.com). That is nonauthoritative, and to be kept visibly separate from the Codification. Note that the same SEC letter asked the operator to state, if true, that contract inception occurs when it validates its own block; what it rejected was a participant in a third-party pool measuring on that basis.

Pool operator: receiving the coinbase output does not make it gross revenue

Now switch perspectives. In a custodial pool the whole reward lands with the operator: "[t]he block reward and transaction fees that come from mining that block are paid to the mining pool. The mining pool pays out a portion of these proceeds to individual miners based on how many shares they generated" (developer.bitcoin.org). A simplistic journal entry records:

Dr Bitcoin                        Cr Revenue - entire coinbase output
Dr Mining expense                 Cr Bitcoin - participant payouts

That can be wrong, in a way that materially overstates both revenue and cost. First the operator must identify the customer, the specified service contracted for, whether it controls that service before it transfers, what portion of the reward is consideration for its own service, and what is owed to participants. Under both IFRS 15 and ASC 606's principal-agent guidance, control of the specified service decides it: holding the payout wallet or being named in the coinbase output is not the test, because the block reward is the consideration, not the service.

Gross versus net is a contract conclusion, not a wallet conclusion

A principal in providing the validation or coordination service may present consideration gross with participant service cost separately; one that merely arranges for others to provide it presents a net fee or commission. The conclusion is contract-specific, and no standard settles it. The mirror image matters just as much: on KPMG's April 2026 reading, a participant that is principal recognises the full reward as revenue with the operator's retained portion as cost of revenue, while an operator that is principal recognises the full reward with amounts remitted to participants as its cost of revenue (kpmg.com).

KPMG's general view is that the operator is typically the principal, because it delegates the work, contracts directly with participants and appears on the chain as miner of record, a firm's expectation about typical arrangements, not a conclusion any entity may adopt without testing its own contract. "The whole coinbase transaction hit our wallet" is not an accounting argument: a protocol receipt identifies who controlled an output, while revenue presentation asks what service the entity provided.

Participant liabilities live in the operator's private ledger

A custodial pool credits participant balances before paying them. Once those credits are enforceable the operator has a liability even though the BTC still sits in its own wallet, and it must reconcile gross reward, subsidy and fee components, its own consideration, participant allocations, unpaid balances, reversals, thresholds and settlements. Do not net that liability against the BTC balance because both are denominated in BTC: offsetting requires the framework's offset criteria, and a shared ticker is not one. Some noncustodial designs instead pay participants without the operator ever controlling all the BTC economically, which allocates control differently and needs its own analysis.

ASIC miners are property, plant and equipment questions

Mining revenue is only half of Bitcoin mining accounting. Commercial mining runs on application-specific integrated circuits (ASICs): chips built to perform one calculation extremely fast and useful for nothing else. Under IFRS, ASICs meeting the recognition criteria are property, plant and equipment under IAS 16, at purchase price plus the directly attributable costs of bringing them into operating condition. US GAAP has no crypto-specific equipment standard, so rigs are long-lived assets under the general guidance in ASC 360-10. Audited practice looks like MARA's, which reports mining rigs within property and equipment at a three-year useful life on the group method (sec.gov). Useful life is an entity-specific estimate reviewed at least annually under IAS 16, not the tax depreciation period, and not the manufacturer's marketing life.

Depreciation begins when the ASIC is available for use

A miner can buy machines in January, install them in February and start hashing in March. Under IAS 16.55 depreciation begins when the asset is available for use (in the location and condition necessary to operate as management intends), so a machine in a warehouse differs from a commissioned machine management chooses not to run because power prices are unattractive.

Temporary idling is the trap. IAS 16.55 also states that depreciation does not cease when an asset becomes idle or is retired from active use unless it is already fully depreciated (though "under usage methods of depreciation the depreciation charge can be zero while there is no production"), so on a straight-line basis curtailing a fleet reduces revenue without reducing depreciation. US GAAP reaches the same place: "[a] long-lived asset that has been temporarily idled shall not be accounted for as if abandoned" (ASC 360-10-35; carried forward unamended from FASB Statement No. 144, paragraph 28).

Impairment is the other half. ASIC economics deteriorate fast, for reasons unrelated to the machine breaking:

rising network difficulty or a falling BTC price;
electricity-price increases, or a newer and more efficient ASIC generation;
physical damage, or regulatory and hosting constraints;
prolonged curtailment, running the fleet below capacity, often under a grid or power contract.

These are impairment indicators, triggering testing under IAS 36 or, under US GAAP, the ASC 360-10-35-21 recoverability test, which applies "whenever events or changes in circumstances indicate that [an asset's] carrying amount may not be recoverable" (FASB Codification). Do not wait for a machine to break.

Hosting and pool contracts can contain leases

Miners frequently buy capacity from hosting providers, and the invoice may say "hosting," "capacity" or "hashrate." No label answers the accounting question, which is whether the contract conveys the right to control the use of an identified asset for a period of time in exchange for consideration: IFRS 16.9 (IFRS 16) and, in almost identical words, ASC 842-10-15-3 (FASB Codification, verified against ASU 2016-02). If the provider can substantively substitute machines and the customer merely receives undifferentiated capacity, the conclusion goes the other way.

The screen runs both ways, easily missed: a pool arrangement can in principle be a lease of the participant's hardware, operator as lessee. KPMG's view is that most are not, because they do not give the operator the right to direct the use of identified hardware (kpmg.com). Document the identified asset, decision rights and substitution facts before choosing between lease and service accounting.

Electricity, hosting and depreciation: expense or inventory cost?

This is the hardest policy area in mining, and two coherent models arise from different facts. Under a service-revenue model, the electricity, hosting and depreciation consumed in providing computational services to a customer are costs of that service, recognised as it is delivered.

Under a production model, where the facts support production of BTC inventory under IAS 2, eligible purchase and conversion costs can enter inventory (IAS 2.10 and IAS 2.12). The exclusions do real work: abnormal wasted materials, labour or other production costs, most storage costs and administrative overheads stay out under IAS 2.16, and fixed overheads are allocated on normal capacity with unallocated overheads expensed as incurred under IAS 2.13, precisely where an idled or curtailed fleet lands.

The same kilowatt-hour cannot be both expensed as a service cost and capitalised into Bitcoin inventory.

US GAAP has no specialised mining production-cost model mirroring the IAS 2 possibility, and the prevailing reading expenses mining operating costs as incurred unless another authoritative model applies, interpretation rather than a stated requirement, and labelled as such. The authority label matters most here: the policy memo must name what the Codification requires, what a handbook suggests, and where judgement was exercised.

A practical mining subledger design

For each mining reward, preserve fields such as:

Field	Why it matters
Mining mode	Solo, pool participant or pool operator
Pool / protocol and contract period	The arrangement, and the measurement-date analysis
Accepted shares	Private evidence of the service
Payout method	PPS, FPPS, success-based or other
Gross reward	Consideration before allocations
Block subsidy and fee reward	Separates protocol issuance from user-funded fees
Pool fee	Contra-revenue, expense or net entitlement
Participant liability	Operator reconciliation
Recognition and payout timestamps	Accounting event time versus settlement time
BTC measurement price	Functional-currency measurement
Transaction ID	On-chain settlement evidence
Accounting lot	Subsequent BTC carrying history

Without these fields the ledger cannot explain why wallet receipts differ from revenue, and that difference, not the wallet balance, is what an auditor asks about. At each close they must tie: shares to the pool statement, accruals to later payouts, invoices to the cost model, commissioning dates to depreciation. Records, controls and reconciliation works that close through; the holding models are covered under IFRS and under US GAAP, the price convention in Bitcoin valuation, and the wider workflow in our crypto accounting guide.

A worked pool-participant example

The pool ledger shows a gross allocation of 0.04829508 BTC, a 2% pool fee rounded to 0.00096590 BTC retained, and a net payout of 0.04732918 BTC. At an illustrative measurement price of $101,321.82/BTC (a one-minute exchange candle close used as this series' convention, not a market-wide "correct" price), that is roughly $4,893.35 gross, $97.87 retained and $4,795.48 net.

If the retained amount is consideration payable to a customer without a distinct service, an IFRS-style presentation might show gross revenue of $4,893.35 with $97.87 as contra-revenue; if it buys a distinct service, or the entitlement is defined net, the presentation differs. The later 0.04732918 BTC payout becomes the participant's Bitcoin asset at a $4,795.48 initial carrying amount. It does not create a second $4,795.48 of revenue.

The assumption behind this example, and a live US GAAP trap. When the amount becomes enforceable and which date prices it are different questions, and only IFRS lets them be answered together, because IFRS 15 sets no measurement date and ASC 606-10-32-21 does. The example assumes an evergreen contract treated as a series of daily contracts, so inception and block success fall on the same day under a consistently applied convention. Without that analysis, pricing success-based rewards at the block-success spot rate uses a method the SEC staff has already objected to in writing.

Bitcoin mining accounting under IFRS and US GAAP at a glance

Issue	IFRS	US GAAP
Comprehensive mining standard	No	No
Participant with a customer	IFRS 15 can apply	ASC 606 can apply
Noncash consideration	Fair value (IFRS 15.66); no date specified	Fair value at contract inception (ASC 606-10-32-21)
Price variability	Outside the constraint (IFRS 15.68)	Constraint addresses other variability
Solo protocol subsidy	IAS 8 policy development	ASC 105 hierarchy
Later BTC holding	IAS 2 or IAS 38	ASC 350-60 if in scope
ASICs, idle or impaired	IAS 16, IAS 36; depreciation continues (IAS 16.55)	ASC 360-10-35-21; not treated as abandoned
Lease screen	IFRS 16.9	ASC 842-10-15-3
Cost model	Service cost, or IAS 2 production cost	Generally expensed as incurred (interpretation)

A navigation aid, not a decision. Mining contracts change results materially.

The questions that remain unresolved

Even in 2026, standard-setting has not answered every mining question, and an accountant should be able to name the open ones: when a solo miner recognises the subsidy, when a pool receivable arises under each payout method, what the operator's specified service is, which costs may be capitalised, and how noncustodial structures allocate control. What accounting standards still do not answer about Bitcoin takes these further. They are reasons to document policy and separate authority from interpretation.

Sources and further reading

Protocol

Bitcoin Developer Guide, Mining: shares, pool workflow, reward distribution. The Developer Guide is a frozen 2020 snapshot and is unmaintained.
Bitcoin Developer Guide, Block chain: coinbase transaction, subsidy plus fees, 100-block maturity and its stale-block rationale.
Bitcoin Core source, consensus.h: COINBASE_MATURITY = 100.
Bitcoin Core source, subsidy implementation: halving every 210,000 blocks.
Block 840,000 on mempool.space and Blockstream: total 40.75061499 BTC = 3.125 BTC subsidy + 37.62561499 BTC fees; mined 20 April 2024.
Braiins Pool, rewards and payouts: one pool's private reward ledger; illustrative of a design, not a universal rule.

IFRS (authoritative)

US GAAP (authoritative)

FASB ASU 2023-08, ASC 350-60
FASB ASU 2016-12, ASC 606 noncash consideration
FASB ASU 2016-08, ASC 606 principal-agent guidance
ASC 105-10-05-2, reproduced verbatim in ASU 2009-01
ASC 360-10-35, carried forward unamended from FASB Statement No. 144
ASC 842-10-15-3, verified against ASU 2016-02, Section A

Regulator correspondence and filed practice (not authority)

SEC staff comment letter to Marathon Digital Holdings (now MARA Holdings, Inc.), 2 February 2024: operator block reward and contracts with customers; the ASC 606-10-32-21 measurement-date objection; PPS versus FPPS disclosure. Staff comment to one registrant on its own facts.
MARA 2025 Form 10-K: audited practice, covering payout-method definitions, contract-inception measurement, mining rigs within property and equipment, dependence on pool recordkeeping.

Firm interpretation (not authority)

KPMG, Crypto mining activities, 4 June 2026: IFRS.
KPMG US, Crypto Assets Handbook, April 2026 (landing page): US GAAP, sections 7.3.10 to 7.3.50.

Educational research, not accounting, tax, legal, valuation or investment advice. It addresses financial reporting by an entity under IFRS Accounting Standards and US GAAP; mining tax differs by country and by whether the miner is an individual or a company, and is covered separately in this series. Mining contracts and operating models vary materially, several positions described here are firm interpretation or regulator correspondence rather than authoritative guidance, and areas without explicit crypto-specific standards require documented professional judgement on the entity's own facts.