TechAccountingProAudit Readiness Checklist for Web3 Startups
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.
[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:
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.
[This post was first published on Substack on July 25, 2025]
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.
[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:
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
