What Accounting Standards Still Do Not Answer About Bitcoin
Where Bitcoin accounting guidance still requires judgment in 2026, including mining, custody, lending, lost keys, Lightning, tax gaps and crypto transfers.
Maksym Buhai
Accounting Engineer
August 28, 2026 · 15 min read

Bitcoin accounting standards are no longer a blank page, but they do not reach every question. Under IFRS a holder's classification runs through IAS 2 or IAS 38, and under US GAAP through ASC 350-60. The useful question is no longer whether Bitcoin accounting standards exist, but which questions they actually reach.
Under International Financial Reporting Standards (IFRS), a holder's classification runs through IAS 2 or IAS 38, the two outcomes the IFRS Interpretations Committee identified in its June 2019 agenda decision. Under United States generally accepted accounting principles (US GAAP), ASC 350-60 measures in-scope holdings at fair value through net income; IFRS 13 and ASC 820 supply the fair-value frameworks.
The hard ones surface where the protocol stops being the whole economic story. A block reward exists because of software rules, not a customer contract. What follows maps those boundaries and names the standard behind each.
When no standard answers the question
The credible response is to name the gap and analyse the transaction, not to invent a rule.
- Is there an explicit standard?If yes, apply it. Most Bitcoin holding and measurement questions are answered.
- Can you reason within the framework?Use the framework's own hierarchy for selecting an accounting policy.
- Document the judgementRecord the alternatives considered and why one was chosen.
- Disclose the policyA disclosed, reasoned judgement is defensible. A silent assumption is not.
Where the gaps sit
- CustodyBTC is not a financial asset, so the financial-asset transfer models do not reach it
- Lending and collateralNo self-contained model for a BTC-denominated return obligation
- Lost keysNo bright-line derecognition trigger
- LightningNo channel-specific recognition or tax framework
The right way to talk about a gap in Bitcoin accounting standards
"Bitcoin accounting standards do not answer this" can mean at least five things, and conflating them is how a policy memo loses an audit argument: no standard was written for the transaction; a general standard applies but judgement must map unusual facts into it; tax law answers where reporting does not, or the reverse; a firm or regulator has published non-authoritative interpretation; or a standard setter is mid-project and has issued nothing final. The goal is to identify where published requirements end and judgement begins, and to say which of the five you are in.
1. Solo Bitcoin mining: what is the recognition credit?
A solo miner whose candidate block wins controls a coinbase output, the output paying that block's subsidy plus the fees of every transaction in it (Bitcoin Developer Guide). The asset side is understandable; the credit is the hard part.
The revenue standards, IFRS 15 and ASC 606, are built around contracts with customers, and IFRS 15.6 applies only where "the counterparty to the contract is a customer." A decentralised network of anonymous nodes is not readily that party: any valid miner may claim the reward, which is no bilateral contract.
Where no Standard applies, IFRS routes preparers to IAS 8.10-11 (a policy built from IFRSs on similar issues, then the Conceptual Framework), with IAS 8.12 allowing recourse to other standard setters, literature and industry practice (IAS 8). US GAAP runs the same hierarchy through ASC 105-10-05-2, requiring an entity to "first consider accounting principles for similar transactions or events within a source of authoritative GAAP" (ASC 105). KPMG's 2026 analysis agrees that judgement decides whether blockchain arrangements give rise to a customer contract (KPMG), which is interpretation, not authority.
Three protocol moments then look tempting: acceptance into the active chain, a chosen number of confirmations, and the end of the restriction under which a coinbase output "cannot be spent ... for at least 100 blocks" (Bitcoin Developer Guide). They answer three different questions (existence, reorganisation risk, spendability), and neither framework turns them into free policy dates.
2. Mining-pool rewards: when does the receivable exist?
Commercial mining usually runs through a pool, which changes the evidence. A pool measures contribution using easier proofs called shares, which are private pool records, not Bitcoin transactions (Bitcoin Developer Guide). It tracks shares, calculates an entitlement, retains a fee and later pays out BTC, Bitcoin's currency unit; one pool calls its "Financial Account" the place "where your mining rewards are stored once confirmed" (Braiins). The economic event arises first in that private ledger:
When has the participant earned an enforceable and measurable amount from the pool?
Payout method matters. Under pay-per-share (PPS) the pool pays a fixed amount per accepted share and absorbs the luck of whether a block is found; full-pay-per-share (FPPS) adds an estimated share of transaction fees. Both can often be estimated before any block succeeds; a success-based method usually cannot. No standard fixes one recognition moment for every pool reward, and tax guidance is thinner still on that timing. Our Bitcoin mining accounting guide works the pool entries through in full.
3. Noncash measurement timing can differ between IFRS and US GAAP
This is a rare place where the frameworks diverge structurally, before any judgement is applied. IFRS 15.66 requires noncash consideration to be measured at fair value but prescribes no measurement date, so the entity adopts and discloses a policy. ASC 606-10-32-21 fixes it at contract inception. Two otherwise identical pool ledgers differ by construction.
That has been enforced. In a comment letter dated 2 February 2024, the Securities and Exchange Commission (SEC) staff told a listed miner that measuring rewards at "the spot rate of bitcoin at the time that the block is successfully mined ... does not comply with the requirement in ASC 606-10-32-21" (SEC). The open issue is not what Bitcoin is worth; it is which event fixes the measurement.
4. Mining-pool operator: principal, agent or something else?
A pool operator may receive the coinbase output, calculate allocations and control the payout wallet, which tempts the conclusion that it earned the gross reward and expenses the miners. That does not follow. Principal-agent analysis under IFRS 15.B34 and its US GAAP counterpart turns on the specified good or service: an entity "is a principal if it controls the specified good or service before that good or service is transferred to a customer" (ASU 2016-08). The reward is consideration, not the service, and controlling the wallet is not the test.
The operator must still identify the customer, the promised service, what it controls, and which portion is its own consideration. No standard has a paragraph headed "Bitcoin mining pool operator"; the ordinary model does the work, contract by contract.
5. Mining costs: service expense or inventory production cost?
Mining consumes application-specific integrated circuit (ASIC) depreciation, electricity, hosting, repairs and pool costs; treatment follows the model chosen for the activity. If a participant provides computational power as a service, those costs can be operating expenses. If it has a supportable production-and-inventory model under IFRS, eligible conversion costs enter inventory: IAS 2.10 requires cost to comprise costs of purchase, conversion and other costs of bringing inventories to their present location and condition, with IAS 2.12 adding a systematic allocation of production overheads.
The models cannot overlap: the same kilowatt-hour cannot be expensed as a service cost and capitalised into BTC inventory. The gap is not that IFRS lacks cost accounting; it prescribes no single mining business model deciding which cost model applies.
6. Custody: when does "BTC" stop being Bitcoin on the holder's books?
A customer deposits Bitcoin with an exchange and the application still shows "10 BTC." What does the customer own? Beneficial ownership of segregated native BTC, an entitlement to identified BTC, an unsecured claim for equivalent BTC, or another right set by the custody agreement and the governing law. The chain cannot tell you which.
Which it is depends on segregation, reuse rights, insolvency treatment, legal title, withdrawal rights and the contract. The standards supply the boundary test: under IFRS the derecognition and control requirements of the applicable asset model, and under US GAAP ASC 350-10-40-1, which routes a nonfinancial asset to Subtopic 610-20, or to Topic 606 where the disposal is a contract with a customer. No standard supplies a custody answer fitting every arrangement. For SEC registrants, SAB 122 rescinded the safeguarding interpretation published as Staff Accounting Bulletin (SAB) 121 in 2022, directing safeguarding entities instead to the ordinary loss-contingency requirements of ASC 450-20 or IAS 37. That answers the safeguarding entity's liability question, not the depositor's asset question this section asks in January 2025, so it removed an interpretation without answering the recognition question. Our SAB 121 explainer traces what the rescission did and did not change.
7. Bitcoin lending: did the lender transfer the asset?
Bitcoin lending looks familiar because the word "loan" is familiar. The asset is not. A borrower can typically sell or reuse the BTC and promises only to return equivalent units, so where control passes the lender holds a contractual right to receive Bitcoin rather than Bitcoin itself.
Under IFRS, that is a right to receive a nonfinancial asset. The IAS 32 definition of a financial asset covers cash, an equity instrument of another entity and a contractual right to receive cash or another financial asset, which is the reasoning behind the IFRS Interpretations Committee's conclusion that a cryptocurrency holding is not a financial asset (IFRIC). Titling the agreement a loan does not convert it. With no IFRS Bitcoin-loan model, the lender works the IAS 8 hierarchy: first whether control transferred, then a reliable policy.
Under US GAAP, nonauthoritative interpretation and SEC staff views fill part of the space. KPMG reports the staff position that on transfer "the lender should recognize a crypto asset loan receivable in their place, measured at the fair value of the loaned crypto assets" (KPMG); the borrower's return obligation is analysed separately (KPMG US handbook). Neither is a Codification model for Bitcoin lending, and collateral, recall and reuse rights move the answer either way. A change is already at ballot. On 19 August 2026 the FASB tentatively decided that "crypto asset lending transactions should not result in derecognition of the transferred crypto assets", and that the lender instead reclassifies the asset as encumbered and captions it separately, with fair value reflecting the counterparty's credit risk, and recognises no separate asset for the right to receive the units back. Staff were directed to draft a proposed ASU with a 60-day comment period (FASB). That is a tentative Board decision and not current GAAP, but it reverses the receivable model above, so do not treat today's treatment as settled.
8. Collateral: restriction or derecognition?
Pledging Bitcoin as collateral does not always produce the same result. If the pledgor retains control and the lender has only a security interest, the BTC can remain an asset subject to restriction and disclosure. If it transfers control, permits reuse, or gives the lender rights that are exercised, the accounting changes, and the test is the derecognition and control analysis of section 6, not the platform's screen wording.
Liquidation then adds timing questions: when control passed, when the liability was reduced, what quantity moved. The chain shows the transfer afterwards but cannot identify the legal moment the collateral rights became enforceable, which is the moment the accounting turns on.
9. Lost private keys: access can vanish before the legal questions settle
A private key can be lost with no Bitcoin transaction. The BTC stays at the same address and, to the network, nothing happened; to the entity, the ability to obtain future economic benefit may have changed completely.
That is the condition the standards test, so this is judgement rather than a void. IAS 38.112 requires derecognition "on disposal" or "when no future economic benefits are expected from its use or disposal," and IAS 38.113 measures the gain or loss as net disposal proceeds, if any, less carrying amount. Under the IAS 38 cost model, IAS 36.9 also requires an impairment-indicator assessment each period end. Under US GAAP the question falls outside ASC 350-60, which does not address derecognition (ASC 350-60-05-2) (ASU 2023-08), and runs through ASC 350-10-40-1. Whether it is met turns on backups, recovery prospects, another authorised signer, claims against a provider, insurance, and whether any realistic route to benefit remains.
No rule says "lost key means derecognise after X days," and the tax answer does not follow the reporting answer. For a United Kingdom individual, HM Revenue and Customs (HMRC) states that "misplacing the key does not count as a disposal for Capital Gains Tax purposes" (HMRC CRYPTO22400), with a negligible-value claim the route to consider. Our article on Bitcoin tax in the UK sets out the wider position that claim sits in.
10. Theft: control, title and recovery can separate
Theft splits three ways: protocol control moves to the thief, legal title can remain with the victim, and recovery depends on insurance, litigation or another claim. Financial reporting decides when the BTC is impaired or derecognised, and whether a recovery meets recognition criteria. Under IFRS a recovery is a contingent asset until it stops being one: IAS 37.33 says contingent assets are not recognised, but "when the realisation of income is virtually certain" the asset is no longer contingent and recognition is appropriate. US GAAP places the question in ASC 450, Contingencies.
Tax reaches a different date. For a United Kingdom individual, HMRC "does not consider theft to be a disposal, as the individual still owns the stolen asset and has a right to recover it" (HMRC CRYPTO22450). The two dates should not be forced to match.
11. Lightning: economic events without public-chain events
Lightning exposes the weakness in "blockchain equals ledger" thinking. A channel opens with a Bitcoin transaction locking BTC into a single output both parties control. The parties then pay each other many times by exchanging cross-signed statements of the channel's current state, which the base chain never sees (Lightning BOLT 5); a closing or splice transaction later returns to the chain. The receipts, payments and routing fees in between are real economic events with no Bitcoin transaction.
For tax, Canada, the United States and the United Kingdom have general rules that can classify the underlying receipt or disposal. None supplies a complete Lightning framework for channel funding, balance changes, routing fees, splicing, close settlement, or the timing gap against chain evidence. A chain-only ledger can be complete at the protocol level and materially incomplete economically.
12. Network fees: accounting is clearer than tax in some jurisdictions
Paying a Bitcoin network fee does two things at once, and most ledgers record only the second.
First, the fee BTC leaves the entity, so those units are derecognised. Their basis is relieved and a gain or loss arises on the fee units themselves. Under IFRS, where BTC is an intangible asset, that is IAS 38.112-113: gain or loss is net disposal proceeds less carrying amount, and gains are never classified as revenue. Under US GAAP the fee units fall outside ASC 350-60 for derecognition (ASC 350-60-05-2) and follow ASC 350-10-40-1.
Second, and only then, is the functional-currency amount classified: an expense, part of the cost of what was acquired, a cost of disposal, or an amount allocated across a batch, according to the purpose the fee served.
Treating the fee purely as a classification question is the common error, and a self-transfer shows why: moving BTC between the entity's own wallets is not a disposal of the quantity that moves, but the fee units are gone. Retain that quantity's basis and remove only the fee units.
Tax guidance is less consistent, and jurisdiction-specific:
- United States. The Internal Revenue Service (IRS) treats digital assets used or withheld to pay a transaction fee as disposed of, the fee then allocated under the transaction and basis rules. But where the fee merely effects a transfer rather than a purchase, sale or disposition, the amount paid is expressly not a digital asset transaction cost (FAQ 53), so it gives no basis relief (IRS FAQs). Check that page's dates: its broker-custody answers, added 15 December 2025, predate Notice 2026-20 and are superseded on that point.
- United Kingdom. HMRC treats a qualifying fee paid to have a transaction included on the ledger as an allowable acquisition or disposal cost (HMRC CRYPTO22150) and, where the fee is satisfied in tokens, also as "a disposal in its own right" at market value under TCGA92/S17(1)(b) (HMRC CRYPTO22280).
- Canada. The reviewed Canada Revenue Agency (CRA) guidance recognises transaction costs generally (proceeds, adjusted cost base or business expense) but publishes no equally explicit Bitcoin-network-fee rule (CRA).
Do not paper over that asymmetry with one "global crypto fee rule."
13. Collateral liquidation and deliberate burns
Two visible on-chain events still have weak event-specific tax guidance: a forced liquidation, where the holder chooses neither moment nor counterparty, and a deliberate send to a provably unspendable output, destroying value with no counterparty and no proceeds. Neither has a complete Bitcoin-specific answer in the reviewed Canadian, United States and United Kingdom sources. The transaction is visible; the tax character is not.
14. Protocol time is not automatically accounting or tax time
Bitcoin produces several time signals: broadcast, mempool acceptance, block timestamp, block inclusion, confirmations, coinbase maturity, reorganisation. None is automatically the recognition timestamp for an invoice, revenue, tax or legal ownership, and a block timestamp is not a precise business timestamp: the miner supplies it within protocol constraints. Retain protocol, contractual, accounting and tax times separately, most of all at a reporting cutoff, where one day moves a transaction across periods.
15. Valuation source failure: the objective, not the outage runbook
IFRS 13 and ASC 820 define the measurement objective: IFRS 13.16 assumes the transaction takes place "in the principal market for the asset or liability" or, absent one, "in the most advantageous market." Neither prescribes:
"If Exchange A's application programming interface (API) fails at 23:59, use Exchange B, then C, then yesterday's close."
That policy belongs to the entity and should be fixed before results are known, covering source outage, stale trades, abnormal spreads, missing intervals, halts, delistings and venue failure. An absent outage paragraph raises rather than reduces the need for a documented, testable one. Our article on Bitcoin valuation for accounting sets out how to write that policy before an outage rather than after it.
16. Deferred tax cannot be calculated from the Bitcoin ledger alone
IAS 12 and ASC 740 provide mature income-tax-accounting models, and the gap is not there. Bitcoin tax basis depends on jurisdiction-specific law, so a carrying amount can be known precisely while deferred tax cannot be computed until the entity establishes tax residence, taxpayer classification, tax basis, tax-lot method, rates, recovery assumptions and uncertain positions.
The frameworks do not even agree on the rate. IAS 12.47 measures deferred tax at the rates expected to apply when the difference reverses, based on rates enacted or substantively enacted by the reporting date; ASC 740-10-30-8 requires enacted law and rates only, so the two can recognise a rate change in different periods.
17. FASB is actively working on crypto transfer accounting
The Financial Accounting Standards Board (FASB) added Accounting for Transfers of Crypto Assets to its technical agenda on November 19, 2025. As of the project page updated July 8, 2026, the work covers expanding the ASC 350-60 scope for certain wrapped and receipt tokens, and clarifying derecognition guidance for crypto transfers by asking whether control has transferred. On April 15, 2026, the Board tentatively decided to revise that scope for crypto assets giving a right to receive another in-scope crypto asset, and to add a disclosure illustration. Derecognition awaits a future Board meeting.
That is evidence that transfer accounting remains a live standard-setting problem, but its status must not be overstated.
Tentative Board decisions and an active project are not current GAAP.
An entity preparing statements today applies the existing Codification, and it is worth naming which part. ASU 2023-08 is explicit that ASC 350-60 does not address the initial measurement, recognition or derecognition of crypto assets (ASC 350-60-05-2). Derecognition of BTC therefore runs through ASC 350-10-40-1 to Subtopic 610-20, or to Topic 606 where the disposal is a contract with a customer. Under IFRS the equivalent test is IAS 38.112-113. Those are today's answers, and our FASB digital asset explainer covers what ASC 350-60 did settle.
18. Writing the policy, and the deeper lesson
A policy memo here does not begin with "industry practice says"; it begins with the hierarchy: IAS 8.10-12 where no IFRS applies (IAS 8), and the ASC 105 hierarchy under US GAAP. It then documents the facts, rights, unit of account, guidance and analogy relied on, alternatives rejected and evidence retained. Secondary accounting-firm literature is useful; label it as interpretation, never as a standard.
The gaps in Bitcoin accounting standards sit on three boundaries: protocol versus contract, key control versus legal ownership, and public evidence versus private economic activity.
None of it makes Bitcoin "unaccountable." It shows where accounting must separate what software interfaces collapse together. A screen can display "BTC" for native Bitcoin, a custody claim, a loan receivable and borrowed units. A chain can display a transfer for a sale, a self-transfer, a collateral movement or a theft. A wallet can select an unspent transaction output (UTXO), one of the discrete chunks of BTC a wallet spends from, unrelated to the lot it should relieve. The problem begins when those representations are treated as equivalent.
Protocol state is evidence. Contracts create rights. Accounting standards classify those rights. Tax law can classify them again.
That is where professional judgement begins. If you want the wider workflow first, our crypto accounting guide shows how recorded events, journal entries and reporting fit together once the judgement is made.
More in this series
Accounting Token Anatomy: Bitcoin. This article stands alone, but the series builds in order.
Previous (01.1.11.4): Bitcoin Tax in the EU: What DAC8 and VAT Do, and What Member States Still Decide
All fifteen articles
- 01.1.1: Bitcoin for Accountants: The Technical Concepts You Actually Need
- 01.1.2: What Do You Actually Own When You Hold Bitcoin?
- 01.1.3: Why the Bitcoin Blockchain Is Not an Accounting Ledger
- 01.1.4: How to Account for Bitcoin Transactions: A Practical Event-by-Event Guide
- 01.1.5: Bitcoin Valuation for Accounting: Which BTC Price Should You Actually Use?
- 01.1.6: Bitcoin Mining Accounting: Rewards, Pools, Revenue, ASICs and Costs
- 01.1.7: Bitcoin Accounting Under IFRS: IAS 2, IAS 38, Impairment and Disclosure
- 01.1.8: Bitcoin Accounting Under US GAAP: ASC 350-60, Fair Value and Disclosures
- 01.1.9: Bitcoin Journal Entries: A Complete Worked Accounting Example
- 01.1.10: Bitcoin Accounting Records, Controls and Reconciliation: A Practical Close Guide
- 01.1.11.1: Bitcoin Tax in Canada: Capital Gains, Business Income, ACB, Mining and GST/HST
- 01.1.11.2: Bitcoin Tax in the United States: Basis, Disposals, Mining and Form 1099-DA
- 01.1.11.3: Bitcoin Tax in the UK: Capital Gains, Section 104 Pooling, Mining and CARF
- 01.1.11.4: Bitcoin Tax in the EU: What DAC8 and VAT Do, and What Member States Still Decide
Sources and further reading
IFRS
- IFRS Interpretations Committee, Holdings of Cryptocurrencies, June 2019: also the source for the IAS 32 financial-asset analysis used in section 7
- IAS 2, Inventories: paragraphs 10 and 12 cited
- IAS 8, Accounting Policies, Changes in Accounting Estimates and Errors: paragraphs 10 to 12 cited
- IAS 12, Income Taxes: paragraph 47 cited
- IAS 36, Impairment of Assets: paragraph 9 cited
- IAS 37, Provisions, Contingent Liabilities and Contingent Assets: paragraph 33 cited
- IAS 38, Intangible Assets: paragraphs 112 and 113 cited
- IFRS 13, Fair Value Measurement: paragraph 16 cited
- IFRS 15, Revenue from Contracts with Customers: paragraphs 6, 66 and B34 cited
US GAAP and SEC
- FASB ASU 2023-08, ASC 350-60 Crypto Assets
- FASB ASU 2016-12, ASC 606 noncash consideration: source of ASC 606-10-32-21
- FASB ASU 2016-08, ASC 606 principal-agent guidance
- FASB ASU 2011-04, ASC 820 Fair Value Measurement
- FASB ASC 105-10-05-2, GAAP hierarchy
- FASB ASC 350-10-40-1, derecognition of intangibles
- FASB ASC 740-10-30, measurement using enacted tax rates
- ASC 450, Contingencies: referenced by Topic only. The three
asc.fasb.orglinks above return a Cloudflare bot challenge to automated fetches, so their paragraph text was not re-retrieved for this article; a reviewer with ordinary browser access should confirm ASC 105-10-05-2, ASC 350-10-40-1 and ASC 740-10-30-8 directly. - FASB, Accounting for Transfers of Crypto Assets, project page updated July 8, 2026: the page itself returns HTTP 403 to automated fetches; the November 19, 2025 agenda addition and the April 15, 2026 tentative decisions were corroborated through contemporaneous trade and firm reporting of those meetings
- SEC staff comment letter to Marathon Digital Holdings, 2 February 2024
- SEC Staff Accounting Bulletin No. 122
Interpretation, not authority
- KPMG, Crypto mining activities, June 4, 2026
- KPMG US, Crypto Assets Handbook, April 2026
- KPMG US, Lenders' accounting for crypto intangible asset loans, January 2023
Tax authorities
- IRS, Frequently asked questions on digital asset transactions: page last updated 29 June 2026; its broker-custody identification answers were added 15 December 2025 and predate Notice 2026-20
- CRA, Information for crypto-asset users and tax professionals: transactions
- HMRC Cryptoassets Manual, including CRYPTO22150, CRYPTO22400 and CRYPTO22450
Protocol documentation
- Bitcoin Developer Guide, Block chain and Mining: a frozen 2020 snapshot, unmaintained
- Lightning specification, BOLT 5
- Braiins Pool, rewards and payouts: documentation for one pool, not a universal pool rule
Educational research, not accounting, tax, legal, valuation or investment advice. This article maps where guidance is incomplete; it does not resolve any of these questions for a particular entity. Standards and tax positions cited were reviewed to 29 August 2026 and can change. Where guidance is incomplete, the specific contract, the governing law and the entity's reporting framework and jurisdiction determine the analysis, and a qualified adviser should be engaged before a position is taken.
Frequently Asked Questions
- Does an active FASB project change how Bitcoin is accounted for today?
- No. Tentative Board decisions and an active project are not current GAAP. An entity preparing statements today applies the existing Codification, and ASU 2023-08 is explicit that ASC 350-60 does not address the initial measurement, recognition or derecognition of crypto assets, so derecognition of BTC runs through ASC 350-10-40-1.
- When is a solo Bitcoin mining reward recognised?
- No standard fixes the moment. IFRS 15 and ASC 606 are built around contracts with customers, and a decentralised network of anonymous nodes is not readily that party, so the preparer works the IAS 8.10-12 hierarchy under IFRS or the ASC 105 hierarchy under US GAAP. Acceptance into the active chain, a chosen confirmation count and the end of the 100-block coinbase restriction answer three different questions, and none of them is a free policy date.
- Do IFRS and US GAAP measure a noncash mining reward on the same date?
- No, and this is a structural divergence rather than a judgement. IFRS 15.66 requires noncash consideration to be measured at fair value but prescribes no measurement date, so the entity adopts and discloses a policy. ASC 606-10-32-21 fixes it at contract inception, and SEC staff have told a listed miner that a block-time spot rate does not comply with that requirement.
- Does losing a private key mean the Bitcoin is derecognised?
- Not automatically. No rule says a lost key means derecognition after a set number of days. IAS 38.112 requires derecognition on disposal or when no future economic benefits are expected from its use or disposal, which turns on backups, recovery prospects, another authorised signer, claims against a provider and insurance. Tax can reach a different answer, and HMRC states that misplacing the key does not count as a disposal for Capital Gains Tax purposes.
- Is a Bitcoin network fee a disposal?
- For financial reporting, yes. The fee BTC leaves the entity, so those units are derecognised, their basis is relieved and a gain or loss arises on the fee units themselves. Only then is the functional-currency amount classified. Tax guidance is less consistent: the United States, the United Kingdom and Canada do not treat a transfer fee the same way, so one global crypto fee rule papers over a real asymmetry.