Subscribe
Support TechAccountingPro
Support this publication to show you appreciate and believe in them. As their writing reaches more readers, your coins may grow in value.
A liquidity pool (LP) is a smart contract that holds a pair or collection of digital assets to facilitate decentralized trading, lending, or other financial services without the need for a centralized intermediary. Users contribute assets to the pool and, in return, earn a share of transaction fees or other incentives.
Liquidity pools are core to decentralized finance (DeFi) protocols like Uniswap, enabling continuous, automated exchange of tokens. Each pool operates on pre-set algorithms that determine asset pricing based on the relative quantities of tokens in the pool.
For token issuers, liquidity pools serve multiple strategic purposes, such as:
enabling access to protocol tokens without the need for being listed on a centralized exchange.
acting as a financing and co-marketing tool, particularly when paired with another token project that may lack liquidity. In such arrangements, both projects can benefit from shared exposure and joint participation in the pool, potentially improving market access and community engagement.
While liquidity pools provide income opportunities and flexibility, they also carry risks such as impermanent loss, smart contract vulnerabilities, and price slippage in volatile markets.
Today, we will discuss how liquidity providers should account for assets contributed to the liquidity pools. We will pay particular attention to simulations of scenarios that involve impermanent loss.
We built a simple LP Pool Model spreadsheet.
Our assumptions are as follows:
The liquidity pool contains two tokens.
Each token in the pool is actively traded on a centralized exchange.
Zero costs to purchase or withdraw assets from centralized exchanges.
Deposits to and withdrawals from accounts on centralized exchanges.
Both tokens in the liquidity pool are in the scope of FASB ASC 350-60, hence:
Both tokens in the pool are issued by unaffiliated third parties
Each tokens are accounted for at fair value.
Liquidity pool protocol follows the constant product formula.
The pool charges a fixed rate paid in tokens that are added to the pool.
From this spreadsheet, we can easily see that regardless of what the fair values of each token are and how these fair values change, whenever there is a trade executed by an arbitrage trader who is trying to capture the arbitrage opportunity, the liquidity pool fair value declines exactly in the same amount as the amount of profit earned by the arbitrage trader. This is true regardless of the level of fees set in the pool.
Generally, the effect of executed trades has a different impact on the total value of LP assets depending on the purpose of the trade:
Speculative trades recapture any profit that could have been accumulated from non-speculative trades.
Non-speculative trades might result in profit or loss for the liquidity pool.
The effect of a speculative trade on the trader who executed the trade successfully is calculated in the example used in our model as follows:
On the opposite side, the effect on the liquidity provider is as follows:
However, there is one scenario where the liquidity pool investment will demonstrate an increase in its fair value. This is a scenario where the prices of both tokens are continuously growing (we have often seen these circumstances in real life back in 2020-2021). Here, the fair value of the liquidity pool will increase at a rate consistent with the lowest of the individual price increase rates of each token in the pool.
Liquidity pools are an important component of the blockchain infrastructure. At the same time, there are many factors complicating the LP accounting:
Both the number and price of tokens in the pool are very volatile.
No direct authoritative guidance exists.
Data is rarely readily available for accounting purposes (especially on non-EVM blockchains).
When used as a co-marketing tool or a way to provide financing to other protocols, assets transferred to the pool might be viewed by management as an expense rather than an investment.
The provider’s portion in the liquidity pool is represented in LP shares, which may or may not be actively traded and may or may not accrue liquidity mining rewards.
Logics and the exact mechanism of the asset flows vary significantly because each decentralized exchange (DEX) implementation of liquidity pools is different.
The liquidity pool accounting is the topic that needs a broader discussion and involvement from industry professionals. This is why it is a suggested topic agenda for the future work of the Web3 Accounting Alliance (W3AA). If you’d like to contribute to the discussion and development of the industry-leading guidance around the accounting for liquidity pools, apply to be a contributor in this topic at the next W3AA meeting to be held on 8/21/2025 at 11 AM EST.
[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.
[First published on Substack]
Why are we talking about DAO grants? Because it is very common for Web3-native companies to receive funding in the form of DAO grants. However, outside of the term ‘grant,’ these arrangements often have little in common. There is no such thing as “standard” anything in Web3. Especially, especially not when it comes to agreement terms. This is why accounting for grants received by commercial entities from a DAO, foundation, or community may become complicated:
Grants often lack legal documentation and clearly defined terms.
Funds are administered by a separate entity, which may or may not be able to provide timely reporting.
As if it were not enough, entities must consider revenue recognition, other income, debt, non-exchange transactions, and other guidance.
To add complexity, funding distributed by DeSci DAOs (e.g., VitaDAO) and projects developing experimental technologies (such as zero-knowledge cryptography) often falls under the complicated guidance of Research & Development (R&D) funding arrangements. By the way, if you’d like to learn more about the DeSci sector, refer to the great post on this topic:
A liquidity pool (LP) is a smart contract that holds a pair or collection of digital assets to facilitate decentralized trading, lending, or other financial services without the need for a centralized intermediary. Users contribute assets to the pool and, in return, earn a share of transaction fees or other incentives.
Liquidity pools are core to decentralized finance (DeFi) protocols like Uniswap, enabling continuous, automated exchange of tokens. Each pool operates on pre-set algorithms that determine asset pricing based on the relative quantities of tokens in the pool.
For token issuers, liquidity pools serve multiple strategic purposes, such as:
enabling access to protocol tokens without the need for being listed on a centralized exchange.
acting as a financing and co-marketing tool, particularly when paired with another token project that may lack liquidity. In such arrangements, both projects can benefit from shared exposure and joint participation in the pool, potentially improving market access and community engagement.
While liquidity pools provide income opportunities and flexibility, they also carry risks such as impermanent loss, smart contract vulnerabilities, and price slippage in volatile markets.
Today, we will discuss how liquidity providers should account for assets contributed to the liquidity pools. We will pay particular attention to simulations of scenarios that involve impermanent loss.
We built a simple LP Pool Model spreadsheet.
Our assumptions are as follows:
The liquidity pool contains two tokens.
Each token in the pool is actively traded on a centralized exchange.
Zero costs to purchase or withdraw assets from centralized exchanges.
Deposits to and withdrawals from accounts on centralized exchanges.
Both tokens in the liquidity pool are in the scope of FASB ASC 350-60, hence:
Both tokens in the pool are issued by unaffiliated third parties
Each tokens are accounted for at fair value.
Liquidity pool protocol follows the constant product formula.
The pool charges a fixed rate paid in tokens that are added to the pool.
From this spreadsheet, we can easily see that regardless of what the fair values of each token are and how these fair values change, whenever there is a trade executed by an arbitrage trader who is trying to capture the arbitrage opportunity, the liquidity pool fair value declines exactly in the same amount as the amount of profit earned by the arbitrage trader. This is true regardless of the level of fees set in the pool.
Generally, the effect of executed trades has a different impact on the total value of LP assets depending on the purpose of the trade:
Speculative trades recapture any profit that could have been accumulated from non-speculative trades.
Non-speculative trades might result in profit or loss for the liquidity pool.
The effect of a speculative trade on the trader who executed the trade successfully is calculated in the example used in our model as follows:
On the opposite side, the effect on the liquidity provider is as follows:
However, there is one scenario where the liquidity pool investment will demonstrate an increase in its fair value. This is a scenario where the prices of both tokens are continuously growing (we have often seen these circumstances in real life back in 2020-2021). Here, the fair value of the liquidity pool will increase at a rate consistent with the lowest of the individual price increase rates of each token in the pool.
Liquidity pools are an important component of the blockchain infrastructure. At the same time, there are many factors complicating the LP accounting:
Both the number and price of tokens in the pool are very volatile.
No direct authoritative guidance exists.
Data is rarely readily available for accounting purposes (especially on non-EVM blockchains).
When used as a co-marketing tool or a way to provide financing to other protocols, assets transferred to the pool might be viewed by management as an expense rather than an investment.
The provider’s portion in the liquidity pool is represented in LP shares, which may or may not be actively traded and may or may not accrue liquidity mining rewards.
Logics and the exact mechanism of the asset flows vary significantly because each decentralized exchange (DEX) implementation of liquidity pools is different.
The liquidity pool accounting is the topic that needs a broader discussion and involvement from industry professionals. This is why it is a suggested topic agenda for the future work of the Web3 Accounting Alliance (W3AA). If you’d like to contribute to the discussion and development of the industry-leading guidance around the accounting for liquidity pools, apply to be a contributor in this topic at the next W3AA meeting to be held on 8/21/2025 at 11 AM EST.
[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.
[First published on Substack]
Why are we talking about DAO grants? Because it is very common for Web3-native companies to receive funding in the form of DAO grants. However, outside of the term ‘grant,’ these arrangements often have little in common. There is no such thing as “standard” anything in Web3. Especially, especially not when it comes to agreement terms. This is why accounting for grants received by commercial entities from a DAO, foundation, or community may become complicated:
Grants often lack legal documentation and clearly defined terms.
Funds are administered by a separate entity, which may or may not be able to provide timely reporting.
As if it were not enough, entities must consider revenue recognition, other income, debt, non-exchange transactions, and other guidance.
To add complexity, funding distributed by DeSci DAOs (e.g., VitaDAO) and projects developing experimental technologies (such as zero-knowledge cryptography) often falls under the complicated guidance of Research & Development (R&D) funding arrangements. By the way, if you’d like to learn more about the DeSci sector, refer to the great post on this topic:
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}\)
Below is a summary approach to help untangle this complex landscape in a real-world environment. It consists of two phases:
Phase 1: Determine the appropriate accounting model, a five-step process for identifying the correct framework:
Phase 2: Apply the appropriate accounting model, covering six possible models applicable to DAO grants.
This phase includes 5 steps.
Step 1: Determine whether the reporting entity is acting as a principal (primarily responsible for service performance and/or in control of the granted funds) or as an agent (merely administering the funds on behalf of the donor or investor). In practice, consider the following indicators:
Does the reporting entity merely administer funds for the grantor?
Is the entity entitled to compensation? If so, the earned portion should be analyzed and accounted for separately.
If the reporting entity acts as a principal, proceed to Step 2.
Otherwise, go to the section “Agency Obligation” below. Note the following definition of an agency obligation, as outlined in accounting codification:
Step 2: In other words, we should evaluate whether the grant creates a debt obligation.
First, assess whether the debt accounting guidance applies. Determine whether the grant includes any obligation to repay proceeds in the future, whether fixed, variable, or conditional. If the grant is concluded to have features of debt or have repayment obligations, proceed to the “Debt” accounting model below.
If the grant is not classified as debt, continue to Step 3.
Step 3: First, we should remember the definition of what a contribution is for accounting purposes under US GAAP:
Now, determine whether the grant qualifies as a non-exchange transaction (i.e., a contribution) based on what is received in return:
Unspecified items* (e.g., general community involvement), items of non-substantial value, or no goods/services at all treated as contributions following the “Non-exchange transactions” accounting model (see the respective section below).
Specified items (in this case, continue to the next step).
* Additionally, consider that other arrangements entered into with the grantor at or around the same time may need to be combined. As a policy, we can define “around the same time” as the period within 3 months from the grant date. If the combined arrangement specifies goods and services being exchanged, then proceed to the next step.
Note. While not explicitly required by accounting standards, we believe that services that are specifically defined in their nature but lack measurability (i.e., users cannot measure the performance progress or determine whether the service obligation has been fulfilled at any given point in time) should be treated as unspecified items.
Step 4: Let’s revisit the definition of R&D under U.S. GAAP:
In essence, Research is a planned activity undertaken to discover new knowledge for the purpose of designing a new product or process or improving an existing product or process. Development is an activity that translates knowledge into a plan or design of a new product or process, or improves an existing product or process.
Armed with this definition, we can now determine whether the transaction is a contribution received. To determine this, assess whether the services provided in exchange for the grant fall under one of the following categories:
(a) Software development services for which technical feasibility has not yet been determined as of the date of the grant agreement, or
(b) Research & development activities (other than software development) when the success of the development is not yet probable due to a substantive R&D risk.
If yes, skip to the section titled “R&D Funding Arrangements”.
If no, proceed to Step 5.
Step 5: Determine whether the assets or services provided in exchange for the grant are part of the company’s ordinary business activities.
If yes, apply ASC 606, as the grant represents a contract with a customer and aligns with the company’s normal revenue-generating activities. Go to the section titled “Revenue from contracts with customers”.
If “no”, then account for the grant under ASC 610 as other income (go to the section “Other income” below).
A. Revenue from contracts with customers
Apply the five-step revenue recognition model under FASB ASC 606. Measure noncash consideration received based on its fair value at the contract inception date. If the grant is received before the satisfaction of performance obligations, the reporting entity should record the proceeds as a contract liability. Once the grant arrangement meets the definition of the contract under ASC 606, recognize the revenue as performance obligations are being satisfied.
Example #A1.
Protocol: ENS
Recipient: Rotki
Source: ENS Public Goods Large Grants Q3 2024 ‘Rotki’
Background: rotki is an open source portfolio management tool that protects your privacy. For developers rotki as a copyleft opensource project provides a lot of important code to accomplish many different tasks. Such as understanding all the protocols we support in all chains, common library code (in python) to do queries related to EVM, Substrate, bitcoin chains, interact with CEXes and more.
Some projects that use rotki's code:
Team requested this grant to help cover as many expenses (dev salaries) towards their goals as possible. Two milestones were set:
01 Odos DEX support in all EVM chains: $12,500 USDC
02 Support extra.finance in all EVM chains: $12,500 USDC
Analysis:
Rotki acts as principal.
No obligation to return funds.
Services were provided in exchange for granted funding.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Revenue
B. Other income
Initial recognition and income measurement will follow ASC 606 (above) guidance. The only difference in accounting relates to the presentation of income, as “Other income” is required. As such, the grant income should not affect the company’s operating results.
A great example of this is a scenario where marketing expense is being reimbursed to a software development company that actively manages the spending and benefits from it through ecosystem growth.
Example #B1: ‘Extend Compound Academy/Education’
Protocol: Compound
Recipient: Compound.Education
Source: QuestBook
Background:
Milestones 1 - Deliver Tidbits & Clickable Demos - 8500 USD
Milestone 2 - Short Videos and Timelines - 8500 USD
Milestone 3 - Two months promotion and third party marketing - 3500 USD
Analysis:
Agent for $3,500 + Principal for $17,000.
No obligation to return funds.
Services are provided in exchange for granted funding.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Revenue for services $17,000 + Agency Obligation for $3,500
C. Agency Obligation
There is no explicit guidance on accounting for agency obligations related to nonfinancial assets received on behalf of the recipient. However, there is guidance for nonprofit entities that gives users the accounting policy choice whether the assets and liabilities should be recognized or left off-balance sheet:
“Agency transaction: A type of exchange transaction in which the reporting entity acts as an agent, trustee, or intermediary for another party that may be a donor or donee.”
[FASB ASC 958-605-20]
Note: This nonprofit guidance is applied by analogy in Web3 when entities act as intermediaries for DAO-controlled funds.
“If an intermediary receives cash or other financial assets, it shall recognize its liability to the specified beneficiary concurrent with its recognition of the assets received from the donor. If an intermediary receives nonfinancial assets, it is permitted, but not required, to recognize its liability and those assets provided that the intermediary reports consistently from period to period and discloses its accounting policy.”
[FASB ASC 958-605-25-23]
Hence, no accounting for received tokens is required in this scenario unless either:
1) The recipient elects to recognize non-financial assets received on behalf of others and related liabilities; or
2) The recipient has a unilateral right to redirect the contribution to another unaffiliated beneficiary.
Note: To clarify, scenario #2 results in the intermediary recipient no longer being considered an agent of the donor.
Even though it is not required, recognition of tokens received on behalf of others and the related agency obligations helps to depict the entity’s financial position more completely and accurately. As such, we do recommend following the recognition path.
If recognized, proceeds are recorded as a liability and subsequently settled against eligible expenses incurred or the amount of grant funds paid out to the ultimate recipient providing the service or transferring the asset.
Example #C1:
Protocol: Cosmos Network
Recipient: Simply Staking
Source: Mintscan
Background:
See COSMOS governance prop #954. Permissionless ICS 3rd Party Audit
Analysis:
Acts as an agent merely administering the funds.
No obligation to return funds.
Specified services are provided.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Agency Obligation for non-commission portion and Revenue for Commission portion.
D. Non-exchange transactions
When the grant arrangement has no specific services specified and no milestones, the contract would not meet the definition of a contract under ASC 606. The grant is in scope and subject to contribution accounting based on the guidance of ASC 720-25 and 958-605 on non-exchange transactions (although ASC 958-605 was designed for non-profits, ASC 958-605-25-2 applies to commercial entities as well).
As per FASB ASC 958-605-25-2, unconditional contributions should be recognized as income in the period received and measured at fair value. This fair value is generally determined based on the date of receipt.
If the entitlement to tokens is subject to certain conditions, income will be deferred until such conditions have been met. But no deferral is required if the condition only places restrictions on the use of tokens but not on the entitlement to tokens (i.e., conditions that prevent the sale of tokens but do not require the return of tokens regardless of whether they are sold or not).
Example #D1
Protocol: NEAR
Recipient: Refound Journalism
Source: PotLock
Analysis:
Acts as a principal.
No obligation to return funds.
Service is defined but there is no specific timing or volume requirements, which means that the service should be treated as if it was not specified.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Non-exchange transaction / Contribution received.
E. R&D funding arrangements
A company should first assess whether the arrangement with DAO possesses all features of a derivative or contains an embedded derivative, and if yes, whether any of the scope exceptions for derivative accounting apply.
Below is the list of relevant scenarios with different accounting outcomes:
Success is probable
Presumptions of debt are present
No presumptions of debt are present
Success is not probable
An obligation to repay exists in case of success
No substantive and genuine transfer of the R&D project risk
Substantive and genuine transfer of the R&D project risk has occurred
Obligation to repay does not exist in any case (including in the case of success)
As the next step, the entity would evaluate whether (at the inception of an arrangement) the successful completion of the program is probable. If the successful outcome is assessed to be probable, the entity would follow FASB ASC 470-10-25 and account for proceeds from DAO as either:
Debt, or
Deferred income
Debt classification is required in circumstances when any of the factors listed in ASC 470-10-25-2 are present:
The grant is legally executed in the form of a debt arrangement.
DAO has the right of recourse to the grant recipient concerning funds provided.
Rights and obligations under the existing funding arrangements can be canceled by lump sum payments or a transfer of assets (e.g., the entity may return the full amount or portion of the funds received from DAO funds if it does not desire to complete the remaining milestones).
DAO has the right (conditional or unconditional) to certain forms of return from the grant, and the rate of return is limited.
DAO has the right (conditional or unconditional) on certain forms of return from the grant, but the amount of return is not affected by the variations of income from the funded operations.
The grant recipient entity is actively involved in the operations that produce a certain form of return due to the DAO.
In cases when the company believes that successful development is not yet probable, the accounting for this arrangement would follow FASB ASC 730-20. Under this guidance, the company needs to evaluate whether the funding is:
Funding repayment liability, or
Contractual obligation to perform services
In other words, receipts of funds may result in a liability to repay or an obligation to perform contractual services.
The accounting depends on whether the substantial and genuine transfer of R&D risks to DAO occurred.
When there is no substantive and genuine transfer of R&D risk to DAO, we record the funding repayment liability. This happens when it is probable that the grant recipient will repay funds received (in full or partially) regardless of the outcome of the R&D projects. The assessment of the probability of repayment should consider:
Actual CONTRACTUAL obligations.
Actual CONSTRUCTIVE obligations.
Potential CONTRACTUAL obligations.
Potential CONSTRUCTIVE obligations.
In FASB ASC 730-20-25-4, 730-20-25-6, we can find examples of facts that create (a) a presumption that the obligation should be classified as debt or (b) evidence that a constructive obligation or commitment exists to repay any of the funds provided, regardless of the outcome of the R&D project:
DAO can require the recipient to purchase the interest that DAO holds in the reporting entity (if any), and this right is not conditional on the success of the project.
Grant recipient (a) *has contractual obligations to repay *or (b) has indicated the intent to repay the funding in full or partially, regardless of the outcome of the project.
DAO has the right to receive in the future debt, equity, or tokens of the entity, regardless of the outcome of the project.
DAO may substitute the initial unsuccessful R&D project to recoup the funding provided or a portion thereof.
DAO funding is received after the project has been essentially completed [1].
Failure to repay the funding received from the DAO would result in a severe economic penalty for a reporting entity, regardless of the outcome of the R&D project.
There is an affiliation between the DAO and the reporting entity [2].
Finally, it is important to note that in accordance with FASB ASC 835, any excess of the amounts expected to be repaid over the amounts originally received should be accounted for as interest costs over the estimated period of repayment. Such excess should NOT be accounted for as part of R&D costs [3].
If the R&D risk was transferred to DAO and such transfer is considered substantive and genuine, the repayment obligation can still exist in case of the successful outcome of the project. Under FASB ASC 730-20-25-8, such a repayment obligation should be accounted for as a contractual obligation to perform services for others. ASC 730-20 does not provide further guidance on the recognition of such an obligation.
Generally, under this scenario, the entity would first evaluate the nature of the services provided. If the R&D services rendered are considered a part of the normal ongoing business operations of the grant recipient, FASB ASC topic 606 would apply, and the funding received should be recorded as revenue.
If the R&D services rendered are not considered normal ongoing business activities of the reporting entity, the recognition of funding in the income statement depends on the accounting policy of the entity. There are two widely adopted accounting policies for the recognition of the funding received under this scenario:
As a Reduction in the direct costs of R&D services rendered, or
As Other income.
Under either of the policy elections, the timing of recognition of the funding received in the income statement will be based on the analysis of the specific terms of the arrangement.
As you may understand, this accounting policy choice may significantly affect the reporting entity's operating margin.
Finally, when no repayment obligation exists, regardless of whether the project outcome is successful or unsuccessful, the reporting entity should follow the accounting guidance for contributions received, as described in Section D, “Non-exchange transactions.”
F. Debt
Recognize the obligation and remeasure at fair value each reporting period-end. The reporting entity should expense crypto assets as the related resources are being consumed. If the repayment of liability will occur under specified conditions, settle the obligation as such repayment occurs, and if the conditions for repayments are not met and no longer expected to be met, and the creditor relieves the claim, then the organization may recognize the obligation as income once the liability has been extinguished under respective codification guidance.
Under ASC 470-10-25, we apply this accounting model to grants received in exchange for services provided to represent research & development activities (other than software development) with an established feasibility.
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}\)
Below is a summary approach to help untangle this complex landscape in a real-world environment. It consists of two phases:
Phase 1: Determine the appropriate accounting model, a five-step process for identifying the correct framework:
Phase 2: Apply the appropriate accounting model, covering six possible models applicable to DAO grants.
This phase includes 5 steps.
Step 1: Determine whether the reporting entity is acting as a principal (primarily responsible for service performance and/or in control of the granted funds) or as an agent (merely administering the funds on behalf of the donor or investor). In practice, consider the following indicators:
Does the reporting entity merely administer funds for the grantor?
Is the entity entitled to compensation? If so, the earned portion should be analyzed and accounted for separately.
If the reporting entity acts as a principal, proceed to Step 2.
Otherwise, go to the section “Agency Obligation” below. Note the following definition of an agency obligation, as outlined in accounting codification:
Step 2: In other words, we should evaluate whether the grant creates a debt obligation.
First, assess whether the debt accounting guidance applies. Determine whether the grant includes any obligation to repay proceeds in the future, whether fixed, variable, or conditional. If the grant is concluded to have features of debt or have repayment obligations, proceed to the “Debt” accounting model below.
If the grant is not classified as debt, continue to Step 3.
Step 3: First, we should remember the definition of what a contribution is for accounting purposes under US GAAP:
Now, determine whether the grant qualifies as a non-exchange transaction (i.e., a contribution) based on what is received in return:
Unspecified items* (e.g., general community involvement), items of non-substantial value, or no goods/services at all treated as contributions following the “Non-exchange transactions” accounting model (see the respective section below).
Specified items (in this case, continue to the next step).
* Additionally, consider that other arrangements entered into with the grantor at or around the same time may need to be combined. As a policy, we can define “around the same time” as the period within 3 months from the grant date. If the combined arrangement specifies goods and services being exchanged, then proceed to the next step.
Note. While not explicitly required by accounting standards, we believe that services that are specifically defined in their nature but lack measurability (i.e., users cannot measure the performance progress or determine whether the service obligation has been fulfilled at any given point in time) should be treated as unspecified items.
Step 4: Let’s revisit the definition of R&D under U.S. GAAP:
In essence, Research is a planned activity undertaken to discover new knowledge for the purpose of designing a new product or process or improving an existing product or process. Development is an activity that translates knowledge into a plan or design of a new product or process, or improves an existing product or process.
Armed with this definition, we can now determine whether the transaction is a contribution received. To determine this, assess whether the services provided in exchange for the grant fall under one of the following categories:
(a) Software development services for which technical feasibility has not yet been determined as of the date of the grant agreement, or
(b) Research & development activities (other than software development) when the success of the development is not yet probable due to a substantive R&D risk.
If yes, skip to the section titled “R&D Funding Arrangements”.
If no, proceed to Step 5.
Step 5: Determine whether the assets or services provided in exchange for the grant are part of the company’s ordinary business activities.
If yes, apply ASC 606, as the grant represents a contract with a customer and aligns with the company’s normal revenue-generating activities. Go to the section titled “Revenue from contracts with customers”.
If “no”, then account for the grant under ASC 610 as other income (go to the section “Other income” below).
A. Revenue from contracts with customers
Apply the five-step revenue recognition model under FASB ASC 606. Measure noncash consideration received based on its fair value at the contract inception date. If the grant is received before the satisfaction of performance obligations, the reporting entity should record the proceeds as a contract liability. Once the grant arrangement meets the definition of the contract under ASC 606, recognize the revenue as performance obligations are being satisfied.
Example #A1.
Protocol: ENS
Recipient: Rotki
Source: ENS Public Goods Large Grants Q3 2024 ‘Rotki’
Background: rotki is an open source portfolio management tool that protects your privacy. For developers rotki as a copyleft opensource project provides a lot of important code to accomplish many different tasks. Such as understanding all the protocols we support in all chains, common library code (in python) to do queries related to EVM, Substrate, bitcoin chains, interact with CEXes and more.
Some projects that use rotki's code:
Team requested this grant to help cover as many expenses (dev salaries) towards their goals as possible. Two milestones were set:
01 Odos DEX support in all EVM chains: $12,500 USDC
02 Support extra.finance in all EVM chains: $12,500 USDC
Analysis:
Rotki acts as principal.
No obligation to return funds.
Services were provided in exchange for granted funding.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Revenue
B. Other income
Initial recognition and income measurement will follow ASC 606 (above) guidance. The only difference in accounting relates to the presentation of income, as “Other income” is required. As such, the grant income should not affect the company’s operating results.
A great example of this is a scenario where marketing expense is being reimbursed to a software development company that actively manages the spending and benefits from it through ecosystem growth.
Example #B1: ‘Extend Compound Academy/Education’
Protocol: Compound
Recipient: Compound.Education
Source: QuestBook
Background:
Milestones 1 - Deliver Tidbits & Clickable Demos - 8500 USD
Milestone 2 - Short Videos and Timelines - 8500 USD
Milestone 3 - Two months promotion and third party marketing - 3500 USD
Analysis:
Agent for $3,500 + Principal for $17,000.
No obligation to return funds.
Services are provided in exchange for granted funding.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Revenue for services $17,000 + Agency Obligation for $3,500
C. Agency Obligation
There is no explicit guidance on accounting for agency obligations related to nonfinancial assets received on behalf of the recipient. However, there is guidance for nonprofit entities that gives users the accounting policy choice whether the assets and liabilities should be recognized or left off-balance sheet:
“Agency transaction: A type of exchange transaction in which the reporting entity acts as an agent, trustee, or intermediary for another party that may be a donor or donee.”
[FASB ASC 958-605-20]
Note: This nonprofit guidance is applied by analogy in Web3 when entities act as intermediaries for DAO-controlled funds.
“If an intermediary receives cash or other financial assets, it shall recognize its liability to the specified beneficiary concurrent with its recognition of the assets received from the donor. If an intermediary receives nonfinancial assets, it is permitted, but not required, to recognize its liability and those assets provided that the intermediary reports consistently from period to period and discloses its accounting policy.”
[FASB ASC 958-605-25-23]
Hence, no accounting for received tokens is required in this scenario unless either:
1) The recipient elects to recognize non-financial assets received on behalf of others and related liabilities; or
2) The recipient has a unilateral right to redirect the contribution to another unaffiliated beneficiary.
Note: To clarify, scenario #2 results in the intermediary recipient no longer being considered an agent of the donor.
Even though it is not required, recognition of tokens received on behalf of others and the related agency obligations helps to depict the entity’s financial position more completely and accurately. As such, we do recommend following the recognition path.
If recognized, proceeds are recorded as a liability and subsequently settled against eligible expenses incurred or the amount of grant funds paid out to the ultimate recipient providing the service or transferring the asset.
Example #C1:
Protocol: Cosmos Network
Recipient: Simply Staking
Source: Mintscan
Background:
See COSMOS governance prop #954. Permissionless ICS 3rd Party Audit
Analysis:
Acts as an agent merely administering the funds.
No obligation to return funds.
Specified services are provided.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Agency Obligation for non-commission portion and Revenue for Commission portion.
D. Non-exchange transactions
When the grant arrangement has no specific services specified and no milestones, the contract would not meet the definition of a contract under ASC 606. The grant is in scope and subject to contribution accounting based on the guidance of ASC 720-25 and 958-605 on non-exchange transactions (although ASC 958-605 was designed for non-profits, ASC 958-605-25-2 applies to commercial entities as well).
As per FASB ASC 958-605-25-2, unconditional contributions should be recognized as income in the period received and measured at fair value. This fair value is generally determined based on the date of receipt.
If the entitlement to tokens is subject to certain conditions, income will be deferred until such conditions have been met. But no deferral is required if the condition only places restrictions on the use of tokens but not on the entitlement to tokens (i.e., conditions that prevent the sale of tokens but do not require the return of tokens regardless of whether they are sold or not).
Example #D1
Protocol: NEAR
Recipient: Refound Journalism
Source: PotLock
Analysis:
Acts as a principal.
No obligation to return funds.
Service is defined but there is no specific timing or volume requirements, which means that the service should be treated as if it was not specified.
Services are not the performance of Research & Development work.
Services are a part of the recipient’s ordinary operations.
Conclusion: Non-exchange transaction / Contribution received.
E. R&D funding arrangements
A company should first assess whether the arrangement with DAO possesses all features of a derivative or contains an embedded derivative, and if yes, whether any of the scope exceptions for derivative accounting apply.
Below is the list of relevant scenarios with different accounting outcomes:
Success is probable
Presumptions of debt are present
No presumptions of debt are present
Success is not probable
An obligation to repay exists in case of success
No substantive and genuine transfer of the R&D project risk
Substantive and genuine transfer of the R&D project risk has occurred
Obligation to repay does not exist in any case (including in the case of success)
As the next step, the entity would evaluate whether (at the inception of an arrangement) the successful completion of the program is probable. If the successful outcome is assessed to be probable, the entity would follow FASB ASC 470-10-25 and account for proceeds from DAO as either:
Debt, or
Deferred income
Debt classification is required in circumstances when any of the factors listed in ASC 470-10-25-2 are present:
The grant is legally executed in the form of a debt arrangement.
DAO has the right of recourse to the grant recipient concerning funds provided.
Rights and obligations under the existing funding arrangements can be canceled by lump sum payments or a transfer of assets (e.g., the entity may return the full amount or portion of the funds received from DAO funds if it does not desire to complete the remaining milestones).
DAO has the right (conditional or unconditional) to certain forms of return from the grant, and the rate of return is limited.
DAO has the right (conditional or unconditional) on certain forms of return from the grant, but the amount of return is not affected by the variations of income from the funded operations.
The grant recipient entity is actively involved in the operations that produce a certain form of return due to the DAO.
In cases when the company believes that successful development is not yet probable, the accounting for this arrangement would follow FASB ASC 730-20. Under this guidance, the company needs to evaluate whether the funding is:
Funding repayment liability, or
Contractual obligation to perform services
In other words, receipts of funds may result in a liability to repay or an obligation to perform contractual services.
The accounting depends on whether the substantial and genuine transfer of R&D risks to DAO occurred.
When there is no substantive and genuine transfer of R&D risk to DAO, we record the funding repayment liability. This happens when it is probable that the grant recipient will repay funds received (in full or partially) regardless of the outcome of the R&D projects. The assessment of the probability of repayment should consider:
Actual CONTRACTUAL obligations.
Actual CONSTRUCTIVE obligations.
Potential CONTRACTUAL obligations.
Potential CONSTRUCTIVE obligations.
In FASB ASC 730-20-25-4, 730-20-25-6, we can find examples of facts that create (a) a presumption that the obligation should be classified as debt or (b) evidence that a constructive obligation or commitment exists to repay any of the funds provided, regardless of the outcome of the R&D project:
DAO can require the recipient to purchase the interest that DAO holds in the reporting entity (if any), and this right is not conditional on the success of the project.
Grant recipient (a) *has contractual obligations to repay *or (b) has indicated the intent to repay the funding in full or partially, regardless of the outcome of the project.
DAO has the right to receive in the future debt, equity, or tokens of the entity, regardless of the outcome of the project.
DAO may substitute the initial unsuccessful R&D project to recoup the funding provided or a portion thereof.
DAO funding is received after the project has been essentially completed [1].
Failure to repay the funding received from the DAO would result in a severe economic penalty for a reporting entity, regardless of the outcome of the R&D project.
There is an affiliation between the DAO and the reporting entity [2].
Finally, it is important to note that in accordance with FASB ASC 835, any excess of the amounts expected to be repaid over the amounts originally received should be accounted for as interest costs over the estimated period of repayment. Such excess should NOT be accounted for as part of R&D costs [3].
If the R&D risk was transferred to DAO and such transfer is considered substantive and genuine, the repayment obligation can still exist in case of the successful outcome of the project. Under FASB ASC 730-20-25-8, such a repayment obligation should be accounted for as a contractual obligation to perform services for others. ASC 730-20 does not provide further guidance on the recognition of such an obligation.
Generally, under this scenario, the entity would first evaluate the nature of the services provided. If the R&D services rendered are considered a part of the normal ongoing business operations of the grant recipient, FASB ASC topic 606 would apply, and the funding received should be recorded as revenue.
If the R&D services rendered are not considered normal ongoing business activities of the reporting entity, the recognition of funding in the income statement depends on the accounting policy of the entity. There are two widely adopted accounting policies for the recognition of the funding received under this scenario:
As a Reduction in the direct costs of R&D services rendered, or
As Other income.
Under either of the policy elections, the timing of recognition of the funding received in the income statement will be based on the analysis of the specific terms of the arrangement.
As you may understand, this accounting policy choice may significantly affect the reporting entity's operating margin.
Finally, when no repayment obligation exists, regardless of whether the project outcome is successful or unsuccessful, the reporting entity should follow the accounting guidance for contributions received, as described in Section D, “Non-exchange transactions.”
F. Debt
Recognize the obligation and remeasure at fair value each reporting period-end. The reporting entity should expense crypto assets as the related resources are being consumed. If the repayment of liability will occur under specified conditions, settle the obligation as such repayment occurs, and if the conditions for repayments are not met and no longer expected to be met, and the creditor relieves the claim, then the organization may recognize the obligation as income once the liability has been extinguished under respective codification guidance.
Under ASC 470-10-25, we apply this accounting model to grants received in exchange for services provided to represent research & development activities (other than software development) with an established feasibility.
Share Dialog
Share Dialog
Share Dialog
Share Dialog
Share Dialog
Share Dialog
