TechAccountingProToken Compensation Accounting
Nuances of Token Compensation in Today's Accounting Landscape
TechAccountingProSustainable Value Frameworks for Web3 Protocol Development Companies
This article examines how different web3 protocol development companies (the "DevCo") work
TechAccountingProLONG-TERM COMPENSATION PLANS
In this post, we revisit and compare two common approaches for recognizing the cost of long-term compensation plans, including both token-based and cash-based awards, under US GAAP.
Support TechAccountingPro
TechAccountingProBitcoin Mining Revenue - Data
Publication about accounting for crypto under US GAAP.
Support TechAccountingPro
TechAccountingProBitcoin Mining Revenue - Data
TechAccountingProToken Compensation Accounting
Nuances of Token Compensation in Today's Accounting Landscape
TechAccountingProSustainable Value Frameworks for Web3 Protocol Development Companies
This article examines how different web3 protocol development companies (the "DevCo") work
TechAccountingProLONG-TERM COMPENSATION PLANS
In this post, we revisit and compare two common approaches for recognizing the cost of long-term compensation plans, including both token-based and cash-based awards, under US GAAP.
Publication about accounting for crypto under US GAAP.
Subscribe to TechAccountingPro
Subscribe to TechAccountingPro
<100 subscribers
<100 subscribers
[This post was first published on Substack on Jan 02, 2025]
Bitcoin mining companies generate highly volatile yields. Revenue generated during the most recent quarter often differs drastically from the same quarter of the previous year and even the immediately preceding quarter. Both analysts and auditors have to deal with large fluctuations in revenue so it may be difficult to determine the underlying cause of changes.
To address this gap, we analyze the effect of changes in bitcoins mined, relative shares of global hash rates, and bitcoin prices over a period from 2021 Q4 to 2024 Q3 for public bitcoin mining companies that regularly share their operating metrics publicly.
We studied a total of 19 bitcoin miners. Among companies in our sample, we notice a variety of patterns of revenue fluctuations:
Today, our focus is on the data used to analyze the fluctuations. We group all of this data into three broad categories:
Company data
Network data
Market data
We believe that the data used was sufficiently reliable for the goals of this analysis. The information was obtained directly from Forms 10-K, 10-Q, and 8-K filed by companies with the SEC (or similar forms filed with other national securities authorities). Most information used was not subject to an independent review or verification with the exception of reported revenue figures that were audited by each company's independent accountant as part of their audits of financial statements filed.
Information was obtained by us via a complex multistep process that was required in order to:
Account for subsequent restatement and inconsistencies between historical data reported by companies in different sources,
Align the reporting periods of issuers with different fiscal year-end dates,
Convert numbers reported in foreign currencies to US dollars.
We also noted the following with respect to the Bitcoin network data used herein. We analyzed multiple data sources and found that network hash rates as published by different providers differ significantly. The reasons for such differences include:
Unavailability of the actual node hash rates (as this data is private)
Use of different aggregate periods for the calculation of the estimated network hash rate
Timezone differences result in slightly different cut-offs used in the calculation of each publisher
A famous off-by-one error in the Bitcoin source code part that determines the algorithm of the calculation of the network difficulty adjustments.
As such, our approach to sourcing the network data was to use the Bitcoin datasets published by Google BigQuery Public Datasets. To ensure the reliability of the data, we performed the following steps:
Assessed the data source: Google BigQuery Public Datasets is a reputable source of blockchain data. The company’s methodology for extraction, transformation, and loading data is publicly available, and the code is open source.
We checked the sequential numbering of blocks in the dataset and extracted data from Google BigQuery Public Datasets using the following SQL query:
WITH grouped_transactions AS (
SELECT
block_timestamp,
block_timestamp_month,
block_number,
is_coinbase,
input_value,
output_value,
fee,
-- Adjust grouping by the last block numbers divisible without a reminder by 2,016 (to disaggregate dificulty adjustment epochs) and 210,000 (to disaggregate the population by halving events)
CAST(FLOOR((block_number-1) / 2016)*2016*1000000+
FLOOR((block_number-1) / 210000)*210000
AS INT64) AS block_group
FROM `bigquery-public-data.crypto_bitcoin.transactions`
)
SELECT
block_timestamp_month,
block_group,
MIN(block_number) AS min_block_number,
MAX(block_number) AS max_block_number,
MIN(block_timestamp) AS min_block_timestamp,
MAX(block_timestamp) AS max_block_timestamp,
SUM(CASE WHEN is_coinbase = TRUE THEN input_value ELSE 0 END)/(100000000) AS Total_Input_Value_Coinbase,
SUM(CASE WHEN is_coinbase = TRUE THEN output_value ELSE 0 END)/(100000000) AS Total_Output_Value_Coinbase,
SUM(CASE WHEN is_coinbase = TRUE THEN fee ELSE 0 END)/(100000000) AS Total_Fees_Coinbase,
SUM(CASE WHEN is_coinbase = FALSE THEN input_value ELSE 0 END)/(100000000) AS Total_Input_Value_NonCoinbase,
SUM(CASE WHEN is_coinbase = FALSE THEN output_value ELSE 0 END)/(100000000) AS Total_Output_Value_NonCoinbase,
SUM(CASE WHEN is_coinbase = FALSE THEN fee ELSE 0 END)/(100000000) AS Total_Fees_NonCoinbase
FROM grouped_transactions
GROUP BY block_timestamp_month, block_group
HAVING MAX(block_number)>0
ORDER BY block_timestamp_month, block_group;As a result, we created a table helper for analytics that allowed us to clearly see the number of blocks produced in each time period, the respective Bitcoin subsidy rates per block, transaction fees paid to miners, and estimated global network hash rates. This technique may be adapted by auditors to perform substantive analytical procedures of bitcoin miner revenue:
We used the Coinbase price on Bitcoin as provided by Coinbase (up to Q2 2024) and subsequently as provided by FRED (due to the discontinuation of the price feed API by Coinbase during Q4 2024).
When assessing the relevance of inputs in the model, we noted the following key considerations:
Horizon of historical data is limited, and none of the companies we researched has published their operating results before 2021.
The sample of companies researched includes both participants and operators of Bitcoin mining pools.
Revenue recognition accounting policies of observed companies have shown a significant degree of variation. See the detailed study of accounting policies here.
Data is aggregated at a quarterly level, although the actual revenue is recognized daily as the product of the quantity by the current fair market value of bitcoins mined.
We use the quantities of Bitcoin as reported by a business. This technically creates a circularity issue, which could have been resolved by replacing the internal data of the company with the external data supplied directly from the mining pool. However, we have not attempted to resolve this issue at this time.
Heterogeneous business models:
Pure bitcoin miners
Data center hosting businesses with Bitcoin mining operations
Diversified validators (both Proof of Work and Proof of Stake protocols)
Energy producers
Some entities report multiple hash rate metrics (such as average hash rate, end-of-month hash rate, total hash rate, operating hash rate, cloud hash rate, deployed hash rate, etc.) while others only disclose one metric without any definition or specification around what this number represents. The average hash rate of self-mining bitcoin operations is the metric that corresponds with the revenue earned by bitcoin miners from block rewards and transaction fees.
Unfortunately, among the companies we analyzed:
Roughly 20% have not reported average or any hash rates at all.
20% of our remaining 80% did not consistently report the same metric each period.
Restatements of this metric are very common and do not require disclosure.
Based on the information reported by companies that disclose multiple metrics, we determined that the highest hash rate reported (typically, deployed/month-end/total hash rate) in the same period on average is 104% higher than the lowest hash rate reported (typically, average/operating hash rate) in the same period by the same company. This means that our analysis of individual companies may be inherently misstated:
However, as I often hear, any estimate is better than no estimate.
Another issue we noted was related to the average prices derived from revenue reported by some of the sampled entities. In particular, we compared the price at which bitcoin produced was recorded as revenue in comparison with the maximum end-of-day market prices observed during each quarter and noticed the two companies that persistently had average calculated prices of bitcoin recorded as revenue at a level higher than the maximum market price observed in the same period.
However, we believe that this discrepancy was driven by the translation of revenues from Canadian to US Dollars using the average quarterly foreign exchange rates.
Cryptocurrency mining revenue plotted against the number of bitcoins mined during the period for each company by quarter also demonstrated the presence of a plausible relationship:
Cryptocurrency mining revenue with the price of Bitcoin:
Similarly, there appears to be a plausible relationship of cryptocurrency mining revenue with the entity's hashrate as % of the network hashrate:
Our bitcoin mining revenue analytical model is based on the inputs used to determine the bitcoin mining revenue - the number of bitcoins mined during the period and the average price of bitcoin during the same period. Further, in addition to the direct inputs, we included factors underlying the change in bitcoins mined (for example, the impact of changes in the relative share of a global hash rate). The precision of our analytical model allowed us to predict the revenue of each company we analyzed with a difference of less than 5% for any of the periods where the information was available:
Today, we reviewed the data used as inputs in the analytical model we developed. Next time, we will review the suggested analytical model and use it to further analyze changes in revenue of individual Bitcoin miners.
[This post was first published on Substack on Jan 02, 2025]
Bitcoin mining companies generate highly volatile yields. Revenue generated during the most recent quarter often differs drastically from the same quarter of the previous year and even the immediately preceding quarter. Both analysts and auditors have to deal with large fluctuations in revenue so it may be difficult to determine the underlying cause of changes.
To address this gap, we analyze the effect of changes in bitcoins mined, relative shares of global hash rates, and bitcoin prices over a period from 2021 Q4 to 2024 Q3 for public bitcoin mining companies that regularly share their operating metrics publicly.
We studied a total of 19 bitcoin miners. Among companies in our sample, we notice a variety of patterns of revenue fluctuations:
Today, our focus is on the data used to analyze the fluctuations. We group all of this data into three broad categories:
Company data
Network data
Market data
We believe that the data used was sufficiently reliable for the goals of this analysis. The information was obtained directly from Forms 10-K, 10-Q, and 8-K filed by companies with the SEC (or similar forms filed with other national securities authorities). Most information used was not subject to an independent review or verification with the exception of reported revenue figures that were audited by each company's independent accountant as part of their audits of financial statements filed.
Information was obtained by us via a complex multistep process that was required in order to:
Account for subsequent restatement and inconsistencies between historical data reported by companies in different sources,
Align the reporting periods of issuers with different fiscal year-end dates,
Convert numbers reported in foreign currencies to US dollars.
We also noted the following with respect to the Bitcoin network data used herein. We analyzed multiple data sources and found that network hash rates as published by different providers differ significantly. The reasons for such differences include:
Unavailability of the actual node hash rates (as this data is private)
Use of different aggregate periods for the calculation of the estimated network hash rate
Timezone differences result in slightly different cut-offs used in the calculation of each publisher
A famous off-by-one error in the Bitcoin source code part that determines the algorithm of the calculation of the network difficulty adjustments.
As such, our approach to sourcing the network data was to use the Bitcoin datasets published by Google BigQuery Public Datasets. To ensure the reliability of the data, we performed the following steps:
Assessed the data source: Google BigQuery Public Datasets is a reputable source of blockchain data. The company’s methodology for extraction, transformation, and loading data is publicly available, and the code is open source.
We checked the sequential numbering of blocks in the dataset and extracted data from Google BigQuery Public Datasets using the following SQL query:
WITH grouped_transactions AS (
SELECT
block_timestamp,
block_timestamp_month,
block_number,
is_coinbase,
input_value,
output_value,
fee,
-- Adjust grouping by the last block numbers divisible without a reminder by 2,016 (to disaggregate dificulty adjustment epochs) and 210,000 (to disaggregate the population by halving events)
CAST(FLOOR((block_number-1) / 2016)*2016*1000000+
FLOOR((block_number-1) / 210000)*210000
AS INT64) AS block_group
FROM `bigquery-public-data.crypto_bitcoin.transactions`
)
SELECT
block_timestamp_month,
block_group,
MIN(block_number) AS min_block_number,
MAX(block_number) AS max_block_number,
MIN(block_timestamp) AS min_block_timestamp,
MAX(block_timestamp) AS max_block_timestamp,
SUM(CASE WHEN is_coinbase = TRUE THEN input_value ELSE 0 END)/(100000000) AS Total_Input_Value_Coinbase,
SUM(CASE WHEN is_coinbase = TRUE THEN output_value ELSE 0 END)/(100000000) AS Total_Output_Value_Coinbase,
SUM(CASE WHEN is_coinbase = TRUE THEN fee ELSE 0 END)/(100000000) AS Total_Fees_Coinbase,
SUM(CASE WHEN is_coinbase = FALSE THEN input_value ELSE 0 END)/(100000000) AS Total_Input_Value_NonCoinbase,
SUM(CASE WHEN is_coinbase = FALSE THEN output_value ELSE 0 END)/(100000000) AS Total_Output_Value_NonCoinbase,
SUM(CASE WHEN is_coinbase = FALSE THEN fee ELSE 0 END)/(100000000) AS Total_Fees_NonCoinbase
FROM grouped_transactions
GROUP BY block_timestamp_month, block_group
HAVING MAX(block_number)>0
ORDER BY block_timestamp_month, block_group;As a result, we created a table helper for analytics that allowed us to clearly see the number of blocks produced in each time period, the respective Bitcoin subsidy rates per block, transaction fees paid to miners, and estimated global network hash rates. This technique may be adapted by auditors to perform substantive analytical procedures of bitcoin miner revenue:
We used the Coinbase price on Bitcoin as provided by Coinbase (up to Q2 2024) and subsequently as provided by FRED (due to the discontinuation of the price feed API by Coinbase during Q4 2024).
When assessing the relevance of inputs in the model, we noted the following key considerations:
Horizon of historical data is limited, and none of the companies we researched has published their operating results before 2021.
The sample of companies researched includes both participants and operators of Bitcoin mining pools.
Revenue recognition accounting policies of observed companies have shown a significant degree of variation. See the detailed study of accounting policies here.
Data is aggregated at a quarterly level, although the actual revenue is recognized daily as the product of the quantity by the current fair market value of bitcoins mined.
We use the quantities of Bitcoin as reported by a business. This technically creates a circularity issue, which could have been resolved by replacing the internal data of the company with the external data supplied directly from the mining pool. However, we have not attempted to resolve this issue at this time.
Heterogeneous business models:
Pure bitcoin miners
Data center hosting businesses with Bitcoin mining operations
Diversified validators (both Proof of Work and Proof of Stake protocols)
Energy producers
Some entities report multiple hash rate metrics (such as average hash rate, end-of-month hash rate, total hash rate, operating hash rate, cloud hash rate, deployed hash rate, etc.) while others only disclose one metric without any definition or specification around what this number represents. The average hash rate of self-mining bitcoin operations is the metric that corresponds with the revenue earned by bitcoin miners from block rewards and transaction fees.
Unfortunately, among the companies we analyzed:
Roughly 20% have not reported average or any hash rates at all.
20% of our remaining 80% did not consistently report the same metric each period.
Restatements of this metric are very common and do not require disclosure.
Based on the information reported by companies that disclose multiple metrics, we determined that the highest hash rate reported (typically, deployed/month-end/total hash rate) in the same period on average is 104% higher than the lowest hash rate reported (typically, average/operating hash rate) in the same period by the same company. This means that our analysis of individual companies may be inherently misstated:
However, as I often hear, any estimate is better than no estimate.
Another issue we noted was related to the average prices derived from revenue reported by some of the sampled entities. In particular, we compared the price at which bitcoin produced was recorded as revenue in comparison with the maximum end-of-day market prices observed during each quarter and noticed the two companies that persistently had average calculated prices of bitcoin recorded as revenue at a level higher than the maximum market price observed in the same period.
However, we believe that this discrepancy was driven by the translation of revenues from Canadian to US Dollars using the average quarterly foreign exchange rates.
Cryptocurrency mining revenue plotted against the number of bitcoins mined during the period for each company by quarter also demonstrated the presence of a plausible relationship:
Cryptocurrency mining revenue with the price of Bitcoin:
Similarly, there appears to be a plausible relationship of cryptocurrency mining revenue with the entity's hashrate as % of the network hashrate:
Our bitcoin mining revenue analytical model is based on the inputs used to determine the bitcoin mining revenue - the number of bitcoins mined during the period and the average price of bitcoin during the same period. Further, in addition to the direct inputs, we included factors underlying the change in bitcoins mined (for example, the impact of changes in the relative share of a global hash rate). The precision of our analytical model allowed us to predict the revenue of each company we analyzed with a difference of less than 5% for any of the periods where the information was available:
Today, we reviewed the data used as inputs in the analytical model we developed. Next time, we will review the suggested analytical model and use it to further analyze changes in revenue of individual Bitcoin miners.
The data produced by this query includes information about total Bitcoin subsidies paid out in each period and also total transaction fees paid in each block. We performed random checks of transactional and block header data against information available in public Bitcoin explorers and against information we queried from a private Bitcoin node we had established access.
We sourced Network difficulty for each epoch from BitcoinExplorer.org and validated it by recalculating each epoch adjustment using the timestamp data from block headers.
We then used the verified Network difficulty and the difference between the average actual time to produce new blocks in each period and the normal time of 86,400 seconds (10 minutes) to calculate the estimated global Bitcoin network hash rate in each period.
\(\begin{equation} \text{Network Hashrate} = \frac{\left( \frac{\text{Actual blocks found}}{\frac{\text{Time Period}}{10 \text{ min}}} \right) \times \text{Difficulty Rate} \times 2^{32}}{600} \end{equation}\)
The data produced by this query includes information about total Bitcoin subsidies paid out in each period and also total transaction fees paid in each block. We performed random checks of transactional and block header data against information available in public Bitcoin explorers and against information we queried from a private Bitcoin node we had established access.
We sourced Network difficulty for each epoch from BitcoinExplorer.org and validated it by recalculating each epoch adjustment using the timestamp data from block headers.
We then used the verified Network difficulty and the difference between the average actual time to produce new blocks in each period and the normal time of 86,400 seconds (10 minutes) to calculate the estimated global Bitcoin network hash rate in each period.
\(\begin{equation} \text{Network Hashrate} = \frac{\left( \frac{\text{Actual blocks found}}{\frac{\text{Time Period}}{10 \text{ min}}} \right) \times \text{Difficulty Rate} \times 2^{32}}{600} \end{equation}\)
Share Dialog
Share Dialog
No activity yet