We put together a checklist covering the key areas finance teams should review before the audit begins.

Download the checklist here:

Audit Readiness Checklist for Web3 Startups

18.9MB ∙ PDF file

Download

This checklist helps Web3 finance leaders prepare for financial statement audits by outlining critical considerations and common pitfalls. If you are preparing for an upcoming audit, this guide will help you identify potential issues early and reduce delays during the audit process. Many Web3 startups discover during their first audit that missing documentation, unclear accounting policies, or weak internal controls can significantly increase audit costs and delay financial statement issuance.

Download

If your company is looking for assistance with the preparation for future audit, of help managing your ongoing audit, reach out.

CONTACT

Email: info@techaccountingpro.com
Link: https://cal.com/andrew-belonogov/30min
Site: https://techaccountingpro.com

Under ASC 710-10-25-9, compensation cost for benefit plans with awards tied to service periods longer than 12 months should be accrued over the service period in a systematic and rational manner. The selected attribution method should be applied consistently and should ensure that:

• Compensation expense is recognized over the requisite service period, which is the period during which an employee must continue providing services to earn the compensation.

• Cumulative compensation cost recognized in each period is at least equal to the cumulative vested portion of the award, meaning the nonforfeitable amount earned to date.

In practice, entities typically apply one of the following accounting policies:

• Award-level straight-line attribution

• Tranche-level accelerated attribution

Each method results in a different cumulative expense recognition pattern. The illustration below compares both methods using a multi-year vesting structure.

Case Study

Scenario

Employees receive cash awards under a compensation plan with the following vesting schedule: 75% in year 2, 20% in year 3, and 5% in year 4, as shown below.

How should the reporting entity recognize the related compensation expense? It depends on the selected accounting policy.

Straight-line Attribution Policy

Under this policy, the full value of the award is recognized on a straight-line basis over the four-year requisite service period. As a result, 25% of the total award is recognized as compensation expense in each year of the four-year vesting period.

The chart below summarizes the financial effects of straight-line attribution by year:

Accelerated Attribution Policy

Under this policy, entities recognize compensation cost separately for each tranche of the award based on its individual vesting date. In the first year, compensation cost is calculated by tranche as follows:

• 50% of the tranche that vests in 2024, which vests 2 years after the award date

• 33% of the tranche that vests in 2025, which vests 3 years after the award date

• 25% of the tranche that vests in 2026, which vests 4 years after the award date

The chart below summarizes the financial effects of accelerated attribution for each year when the expense is recorded:

Straightline vs. Accelerated Attribution

The chart below compares the results of each policy election in the case study above.

You can find the Google Sheet with the calculations here.

For additional discussion of token compensation plans, see the related post below:

If you think this content might be helpful to someone else you know, please share it.

This article examines how different web3 protocol development companies (the "DevCo") work and answers the following questions:

• How does DevCo create value for its shareholders?

• What sustainable business models are used by different DevCos?

• What impact does the use of different business models have on accounting?

Background

A defining characteristic of most DevCos is the absence of traditional revenue, especially in early stages. The core team initially raises capital privately. That capital is deployed into initial protocol development and ecosystem building. Once the protocol is live and tested, additional funding is typically raised during a token generation event, often through a substantial allocation of tokens to the DevCo's treasury. Additional capital may come from public token sales or from crypto-focused VCs.

From that point onward, DevCo's management focuses on growing the ecosystem and maintaining the protocol. Growth is driven by adoption activated through marketing and partnerships, and sustained through transparent protocol governance, support of other builders, and continuous maintenance and development. Growth often translates into appreciation of assets held in the company’s treasury.

Once a network becomes operational, it begins generating real economic value through transaction fees and charges for consumption of protocol utility. However, that value does not accrue directly to the DevCo. It is ecosystem revenue, distributed to validators, operators, delegators, and other participants through protocol mechanisms. Ecosystem revenue reflects protocol value creation, but it does not, by itself, characterize the value of an equity interest in the DevCo.

This helps explain why so many projects appear to operate without traditional revenue for extended periods. KuCoin Exchange recently highlighted that 99% of web3 projects sustain themselves primarily through token funding and investor capital rather than operating cash flows. This observation often draws criticism, but from another perspective, it reflects a deliberate adoption-first strategy. Teams and investors are underwriting scale and engagement today, believing that durable value emerges later. Whether this will play out the same way it did in earlier technology cycles remains uncertain, but the belief itself is understandable.

In practice, DevCos monetize their position through a broader set of cash flow and quasi-cash flow mechanisms than is often modeled. Common sources include:

• Staking rewards

• Initial token allocations

• Token sales and structured unlocks

• Service fees paid by protocol

• Governance-related income

• Commissions from incubated or managed ecosystem projects

• Investment income

• Derivative or hedging arrangements

How these mechanisms translate into sustainable value depends on the underlying business model the DevCo chooses to pursue.

Four sustainability models and their economic logic

Across projects and conversations, four models consistently emerge. Each reflects a different strategic posture and leads to different economic and accounting outcomes.

1) Studio (Diversified Software Development Model)

In this model, the DevCo positions itself primarily as a software development organization. The value creation is driven by engineering services, infrastructure development, and long-term partnerships. Growth comes from scaling these capabilities across ecosystems.

From an accounting perspective, token presales are best understood as financing arrangements rather than operating revenue. Although classification depends on contractual rights and restrictions embedded in the token instruments, sales of tokens from treasury are generally more appropriately treated as non-operating asset sales, separate from core software development services.

Examples: Polygon Labs, Offchain Labs, ConsenSys

2) Farm (Build-and-Rotate Model)

Here, the DevCo repeatedly initiates new protocols, invests heavily in adoption and engagement, and treats tokens as the primary economic output of its activities, similar to an inventory build-and-monetize cycle.

In this structure, token investors are customers of the DevCo, and the performance obligation is to deliver tokens rather than provide services. Token presales function as prepayments for future token deliveries and may include a significant financing component. Once tokens are live and delivered as part of ordinary activities, token sales can align with operating revenue. However, all facts and circumstances must be evaluated, particularly whether tokens are outputs of ordinary activities or passive treasury assets.

Examples: Mysten Labs

3) Guild (Network Revenue Sharing Model)

In this approach, the DevCo’s value creation is explicitly tied to network outcomes rather than treasury appreciation. The organization participates in ecosystem economics through revenue-sharing mechanisms. This might be implemented as:

• Direct fee distribution, or

• Indirect fee distribution (Token buybacks)

This model creates strong alignment between DevCo value and protocol utility, adoption, and ecosystem growth.

The success of this model depends on the primary driver of value creation, which can include:

• Ecosystem customer loyalty,

• Unbeatable technological advantage of the protocol, or

• Price leadership.

From an accounting perspective, both token presales and token sales are generally viewed as financing arrangements representing the sale of future network revenue. Customers are end users of the protocol, and the DevCo’s performance obligation relates to facilitating protocol services through infrastructure management rather than selling tokens as products or acting as a validator or operator.

Whether network income is operating revenue or income from a collaborative arrangement depends on the DevCo’s role and all relevant facts and circumstances.

Examples: Virtuals Protocol, Balancer, Nova Labs

4) Abbey (Endowment Treasury Model)

This model emphasizes long-term mission, governance independence, and sustainability. Core activities are supported by a diversified treasury designed to generate yield sufficient to fund operations and ecosystem development indefinitely.

Here, token presales function as financing arrangements. Token sales from treasury are treated as non-operating asset sales, analogous to portfolio management rather than operating performance. Other yield generated from treasury assets is passive investment income. This structure allows leadership to prioritize long-term network health and mission alignment, even when those choices may be detrimental in the short term. A natural question in this model is whether any income generated can be classified as operating rather than investing in nature.

Examples: Polkadot, Filecoin Labs, Solana Labs

Conclusion

Across all four models, a common theme emerges: strategy determines economics, and economics should determine accounting treatment, not the reverse. Attempts to impose a single revenue narrative across fundamentally different models tend to obscure how value is actually created and sustained.

As the industry matures, more efforts are emerging to coordinate the interests of equity holders and token holders within coherent frameworks, making these structures more legible from a governance, funding, and value creation perspective. One such effort is the STAMP framework recently introduced by Colosseum, which will be explored in more detail in a future publication.

I recently spoke with several technical accounting professionals about how they account for various forms of token compensation and was surprised by the diversity of approaches. Today, we will take a detailed look at the accounting for token compensation.

Let’s start by defining what token compensation is:

Token compensation is a benefit plan established by an entity in which employees receive project tokens or other tokens issued by the employer, or where the employer incurs liabilities to employees based on the price of these project tokens.

We will specifically exclude from our discussion any plans where tokens represent stock in the company’s equity or provide the employee with rights similar to those of equity holders. Accounting for these compensation plans is likely guided by stock-based compensation accounting rules, which is a separate and extensive topic that we cannot cover in a single blog post. Instead, we will focus on more traditional forms of token compensation plans.

Web3 companies often offer employees various token compensation plans, and these plans frequently have unique and unusual terms. Toku, a company specializing in the administration of token compensation, has published research showing that the three most common plans offered to employees of crypto-native companies are:

• Restricted Token Awards (RTAs). These are grants of tokens in exchange for services, with the immediate transfer of tokens to the employee’s wallet or smart contract. These tokens come with programmatic restrictions on transfer and enforce vesting conditions (unvested tokens are subject to clawback in case of termination). These awards are typical for projects that have already minted tokens but have not yet initiated a public sale.

• Token Purchase Agreements (TPAs). Employees purchase tokens at an agreed-upon below-market price. These agreements may also offer employees protection from downside market movement to avoid a situation where employees end up with a loss position that effectively reduces their compensation.

• Restricted Token Units (RTUs). Similar to RTAs, but tokens are only transferred to employees at the vesting date, typically in quarterly tranches over a four-year vesting term with a one-year cliff. RTUs are common for projects that have already publicly launched tokens.

Entities account for token compensation plans by recognizing the anticipated payout over the service period in a systematic and rational manner as per [ASC 710-10-25-9]. This systematic approach is generally implemented via one of two methods:

• Accelerated expense attribution

• Straight-line expense attribution

Both methods recognize expenses over the vesting period as illustrated below:

Generally, labor costs should be recognized over the period of requisite service, with the full amount of expense recognized at the earliest of when the expense (or its portion) [FASB ASC 710-10-20, -30]:

• Has been earned and

• Becomes unforfeitable

In practice, this means that the amounts calculated using either expense attribution method need to be compared to the total value of vested tokens as of each reporting date. When the value of vested tokens exceeds the recognized expense, an additional catch-up expense should be recorded in the month of the variance.

Classification of the token grant obligation. Because project tokens within the scope of this post do not provide interest in the entity’s residual assets, token grant obligations are treated as a company liability rather than a component of equity.

However, it is useful to consider the guidance on accounting for stock-based compensation costs arising from liability-classified awards. Under US GAAP, these awards are measured each reporting period, and changes in fair value are recorded as compensation expenses. However, the accounting model for liability-classified stock awards is actually the model for financial liability-classified stock awards. In contrast, token awards result in token grant liabilities that may be financial or non-financial liabilities depending on the terms of the specific plan. If the token grant liability is a financial liability, we could follow the guidance for liability-classified stock-based compensation as an analogy. However, the accounting for non-financial token grant liabilities has distinct features:

• Host contract liability is measured using inception date token prices

• Embedded derivative asset/liability is used to track changes in the fiat value of the token grant liability due to changes in token prices. Embedded derivative assets/liabilities are presented separately from the token grant liability [1]

• Unrealized remeasurement gain/(loss) on embedded derivatives accounts for changes in the valuation of token grant liability resulting from changes in token prices. This gain/(loss) may be presented as part of the compensation expense or separately in another caption of the operating results section in the P&L.

Token compensation expense should initially be recorded as:

DEBIT Compensation Expense

CREDIT Token Grant Liability

Subsequently, the pro-rata vested portion of the token grant liability is remeasured each reporting date and recorded as a liability with a corresponding compensation expense. In other words, token grants should be expensed on a tranche-by-tranche basis over the vesting term of each tranche, and each tranche is remeasured based on active market price. This results in front-loaded expense recognition.

Performance and market conditions. Token compensation plans may contain performance or market conditions. Accounting for these conditions follows the guidance of ASC 710. Entities should accrue compensation costs over the requisite period of employees’ service, if they believe that (it is probable that) performance conditions will be satisfied. When the performance condition is assessed as not probable, no cost is recorded, and any previously recorded cost is reversed. When management changes its assessment and believes the performance condition is probable, the adjustment to compensation costs may be recorded using either the cumulative catch-up or prospective method:

• Cumulative catch-up method:

  • Recognize separately as catchup adjustments the probable estimated compensation expense that would accrue if the condition was originally estimated as probable. Record such adjustments in the period of assessment change.

  • Recognize the remaining probable estimated compensation expense over the period when future service is rendered.

• Prospective method:

  • Recognize the total probable estimated compensation expense over the remaining period prospectively.

Forfeitures. As mentioned earlier, unvested tokens of terminated employees are often subject to clawback, meaning they are forfeited at the termination date. Similar to cash compensation plans, there is no specific guidance on accounting for forfeitures in token compensation plans. By analogy with ASC 718, management may choose to estimate future forfeitures. However, entities using token compensation plans typically lack sufficient historical data to form a reasonable estimate of such forfeitures, as these entities are often startups. As a result, the best practice is to record actual forfeitures of benefits under token compensation plans as they occur.

Several factors are important to consider when the token grant liability is being settled:

• Reclassify cumulative remeasurement gain/(loss) from unrealized to realized.

• Recognize the settlement gain that effectively offsets all historical token compensation expenses. This results from the fact that the token grant liability is settled by payments of tokens issued by the company, which have zero book value.

• Derecognize embedded derivative/assets (if any) related to the settled token grant obligation.

• Tax withholding obligations should be accounted for as appropriate for the type of grant being settled.

A sample journal entry is presented below:

DEBIT Token Grant Liability

DEBIT Embedded Derivative Liability

CREDIT Embedded Derivative Assets

CREDIT Digital Assets

CREDIT Realized Gain on Disposal of Tokens

DEBIT Realized Loss on Disposal of Tokens

CREDIT Tax Withholding Obligations

As mentioned earlier, token grant liabilities may include both financial and non-financial liabilities depending on the plan terms.

For financial token grant liabilities, it makes sense to adopt the modification accounting model from liability-classified stock-based compensation:

“The general principle of exchanging the original award for a new award also applies to a modification of a liability-classified award. Unlike an equity-classified award, however, a liability-classified award is remeasured at fair value at the end of each reporting period. Therefore, a company simply recognizes the fair value of the modified award by using the modified terms at the modification date. There is no “floor” or requirement to recognize at least as much as the grant-date fair value of a liability classified award; the total compensation expense will equal the fair value on the settlement date.”

[“Stock-Based Compensation Guide” by PwC]

Currently, no explicit guidance exists on the accounting for modifications of non-financial token grants. Further, available analogies are not fully applicable. We generally believe that the “floor” requirements to recognize token compensation expense may apply to modifications of token grants accounted for as non-financial liabilities, but there is no authoritative reference to help determine whether this accounting treatment is appropriate.

Let’s examine some illustrative examples of how the guidance we’ve discussed applies to different types of token compensation plans, including those we identified at the beginning of this post and some additional types discussed below.

Illustration 1 - Restricted Token Agreements

Because the employer may maintain effective control over unvested tokens stored in separate accounts, we should evaluate:

• Whether tokens should be recorded on the employer’s books before vesting.

• How the employer should recognize and present the values of token grant liability for tokens recognized on the employer’s balance sheet.

In most cases, accounting should follow the analogy with the accounting for deferred compensation plans with assets held in a Rabbi Trust. Based on this approach:

• Unvested tokens are recorded on the company’s books as assets (although these assets will likely have no book value).

• Token grant liabilities are recorded separately and on a gross basis. Token grant liabilities are derecognized as tokens vest and become unrestricted.

Illustration 2 - Token Purchase Agreements

The discount to fair value should be recorded as a compensation expense.

Illustration 3 - Restricted Token Units

Record expenses based on the fair value of each vested tranche as they are transferred to employees.

Illustration 4 - Impact of Different Types of Vesting Schedules

The Token Compensation Guide by a16z identifies three types of token vesting schedules most commonly used by crypto startups:

1. Four-year vest with a one-year cliff

“In this model, employees get a batch of tokens when they’re hired. The first quarter of the grant vests after the first year, and a percentage of the remaining tokens vest each month (or quarter or year, etc).”

[Token Compensation Guide by a16z]

Expense Attribution for Four-year vest with a one-year cliff vesting schedule

1. Annual grants

“Given how much token prices change over time, some teams find that it doesn’t make sense to grant tokens over multiple-year periods. This model therefore favors offering awards on a yearly basis. Each employee would get an annual market-rate token grant. Then, after the first grant, talent teams typically add performance metrics to the calculation.”

[Token Compensation Guide by a16z]

Expense Attribution for Annual grants vesting schedule

*Percentages shown for annual grants may be a little bit confusing. Let me explain. We wanted to illustrate the portion of total compensation expense recognized during each of the four years of the vesting schedule. However, for annual grants, the full amount (or 100%) is vested each single year. From the perspective of the four-year time horizon, the same amount comprises 25% of the total token compensation costs (assuming all other variables remain the same in each period, which is clearly an unrealistic assumption).

1. Backloaded four-year vest

“This model is designed to keep employee engagement high — by increasing the size of the vest over time, starting with a smaller percentage (say, 10%), and working up to 100% vested at the end of four years. This model also often involves a 1-year cliff – very few companies would offer tokens that vest without a cliff.”

[Token Compensation Guide by a16z]

Expense Attribution for Backloaded Four-Year vesting schedule

Understanding the nuances of accounting for token compensation is crucial for accountants in web3. As token compensation plans continue to evolve, accounting professionals need to stay informed about best practices and emerging guidance to ensure accurate and compliant financial reporting.

FOOTNOTES

[1] Reporting entities may elect the fair value measurement option to revalue the liability denominated in assets readily convertible to cash as of each reporting date based on updated token fair values.

REFERENCES

“Stock-Based Compensation Guide” by PwC

“Token Compensation Guide” by a16z

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:

1. Both the number and price of tokens in the pool are very volatile.

2. No direct authoritative guidance exists.

3. Data is rarely readily available for accounting purposes (especially on non-EVM blockchains).

4. 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.

5. 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.

6. 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.

INTRODUCTION

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

RELIABILITY

Level 1 - Company 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.

Level 2 - Network data

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;

• 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}\)

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:

Level 3 - Market data

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).

RELEVANCE

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

CONSISTENCY

Hashrate - Nonstandardized and Loose

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.

Principal Market Pricing - Volatile and Impossible

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.

PLAUSABILITY

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:

PREDICTABILITY

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:

CONCLUSION

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.

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:

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:

1. 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).

2. 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:

• A chrome extension that connects to rotki and pulls data

• An extension to overlay rotki's opensource decoders on etherscan

• A plain text accounting tool built on top of rotki

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:

1. Rotki acts as principal.

2. No obligation to return funds.

3. Services were provided in exchange for granted funding.

4. Services are not the performance of Research & Development work.

5. 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:

1. Agent for $3,500 + Principal for $17,000.

2. No obligation to return funds.

3. Services are provided in exchange for granted funding.

4. Services are not the performance of Research & Development work.

5. 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:

1. Acts as an agent merely administering the funds.

2. No obligation to return funds.

3. Specified services are provided.

4. Services are not the performance of Research & Development work.

5. 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:

1. Acts as a principal.

2. No obligation to return funds.

3. 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.

4. Services are not the performance of Research & Development work.

5. 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:

1. Success is probable

   1. Presumptions of debt are present

   2. No presumptions of debt are present

2. Success is not probable

   1. An obligation to repay exists in case of success

      1. No substantive and genuine transfer of the R&D project risk

      2. Substantive and genuine transfer of the R&D project risk has occurred

   2. 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.