8.4 Crypto Assets Received for Goods or Services Provided

When an entity accepts crypto assets in exchange for goods or services provided, the entity will need to use judgment to determine how to account for the crypto assets received. The entity will first need to determine whether it has a contract with a customer, as defined in ASC 606. If the entity determines that the transaction is a contract with a customer, the transaction is within the scope of ASC 606.2 Under ASC 606, the entity would account for the crypto assets received as noncash consideration and, therefore, the crypto assets must be measured at fair value at contract inception. Subsequent changes in the fair value of the crypto assets would not affect the amount of revenue recognized for the goods or services provided. For more information about noncash consideration, see Section 6.5 of Deloitte’s Roadmap Revenue Recognition.

If the transaction is not a contract with a customer, the entity would need to consider other accounting guidance to apply to the transaction, which could include ASC 610-20 (on gains and losses from the derecognition of nonfinancial assets), ASC 845 (on nonmonetary transactions), or applying ASC 606 by analogy.

8.4.1 Mining

A “proof-of-work” blockchain protocol, such as the BTC blockchain, is one in which blocks of transactions are validated by solving a cryptographic algorithm through a process referred to as mining. Those that perform mining activities are referred to as miners. Miners use hardware and software to solve the cryptographic algorithm for a block of transactions, thereby attaching the transactions in the block to the blockchain. To incentivize mining activities, miners are typically rewarded with (1) newly created crypto assets for being the first to solve the cryptographic algorithm and thus validate the block of transactions (referred to as a block reward) and (2) the transaction fees associated with the transactions they validated.

Mining requires highly specialized computer servers that run software designed specifically to mine the crypto assets. A block’s algorithm can only be solved by running the algorithm repeatedly to find a possible solution. Accordingly, miners with the largest share of computing power (or hash rate, which is measured in terms of the number of cryptographic algorithms solved per second) are more likely to be successful in mining efforts because they can run more algorithmic equations in an attempt to determine the block’s solution than miners with less available hash rates.

8.4.1.1 Accounting Issues for Miners

Question 27 of the AICPA Practice Aid provides guidance on how mining entities should recognize transaction fees and block rewards earned in connection with mining activities. For transaction fees, the AICPA Practice Aid states that “Transaction fees earned by a miner should be recognized as revenue from customers in accordance with FASB ASC 606.” The AICPA Practice Aid explains that a contract with a customer exists under ASC 606 because the requester (the one who initiated the crypto asset transaction) has contracted with the miner to obtain a service (successful mining) that is an output of the miner’s ordinary activities in exchange for consideration. The Practice Aid also explains how the other criteria for identifying a contract with a customer under ASC 606 are met, as prescribed by ASC 606-10-25-1. The miner’s performance obligation is satisfied when the miner successfully adds the requester’s transaction to the blockchain, at which point the miner should recognize revenue. The transaction fees are a form of noncash consideration, which is measured at its estimated fair value at contract inception under ASC 606-10-32-21.

In addition, Question 27 of the Practice Aid states that block rewards earned by a miner “are generally recognized as revenue, but evaluation is required to determine if the block rewards earned should be recognized as revenue from contracts with customers under FASB ASC 606 or as other revenue.” The Practice Aid explains that the mining entity would need to evaluate whether its mining activities represent a contract with a customer under ASC 606-10-25-2 and whether all of the criteria under ASC 606-10-25-1 are met. If the mining entity concludes that the block rewards do not represent revenue from contracts with customers under ASC 606, it should consider other recognition guidance. Because there is no other guidance on point for block rewards, a mining entity could apply the guidance in ASC 606 by analogy to recognize and measure revenue associated with block rewards. Under ASC 606-10-50-4(a), if an entity is analogizing to ASC 606 for revenue recognition purposes, the block rewards would need to be presented separately from revenue within the scope of ASC 606 on the face of the financial statements.

8.4.1.2 Mining Pool

A mining pool is a group of miners organized and operated by a third party (referred to as a mining pool operator) that pools the resources of individual miners to share their processing power over a network to solve blocks. Joining a mining pool is a way to decrease the risk of an individual miner’s mining activities by reducing the variability in timing of earning mining rewards. The block rewards and transaction fees earned by the mining pool are allocated to the mining pool participants on the basis of an agreed-upon payout method (often proportionate to the participant’s share of the total mining pool hash rate provided).

Question 28 of the Practice Aid provides guidance on how a mining pool participant should account for the mining pool arrangement. The mining pool participant should first evaluate whether the arrangement between the entity and the mining pool operator includes a lease within the scope of ASC 842. The mining pool operator’s ability to dictate when the mining pool participant can use its mining equipment could indicate that the mining pool participant is leasing the mining equipment to the mining pool operator. If the entity concludes that the mining pool arrangement contains a lease, the entity would apply the lessor accounting guidance under ASC 842. If there is a lease, the mining pool participant’s customer for the lease will generally be the mining pool operator, which means that the mining pool operator would be the principal to the mining activities undertaken in the mining pool.

If the mining pool arrangement does not contain a lease, the mining pool participant will then need to determine whether it is providing its mining services to the mining pool operator or to the blockchain or blockchain participants. To determine the counterparty in the arrangement, the entity would need to determine whether it or the mining pool operator is the principal for the mining activities performed on the blockchain in accordance with the principal-versus-agent guidance in ASC 606. The principal in the arrangement is the one that controls the mining services being performed on the blockchain. See Chapter 10 of Deloitte’s Roadmap Revenue Recognition for more information about principal-versus-agent considerations. Question 28 of the Practice Aid provides the following nonexhaustive list of questions to help entities perform the principal-versus-agent analysis:

“Does [the mining pool operator] direct (that is, assign) to the mining pool participants [including the entity] the mining activities they undertake as part of the pool?”
“Is [the mining pool participant] or [the mining pool operator] primarily responsible for selecting the transactions to be mined, the activities to be performed, placing the mined block on the blockchain, and collecting the block reward?”
“Does [the mining pool participant] bear the risks and rewards associated with the mining activities? For example, is [the mining pool participant] compensated on a fixed basis per unit of computing power delivered or, instead, allocated a percentage only of the actual rewards earned based on the results of the mining activities?”

If the mining pool participant determines that it is providing mining services directly to the blockchain or blockchain participants (i.e., it is the principal in the arrangement), the mining pool participant should apply the guidance addressed in Question 27 of the Practice Aid, as discussed in Section 8.4.1.1, to account for the agreement. If the mining pool participant determines that it is providing services to the mining pool operator, it needs to determine whether the mining pool arrangement is a contract with a customer under ASC 606. If the mining pool participant determines that the arrangement represents a contract with a customer, it should apply the guidance in ASC 606 to recognize revenue from the contract. If the mining pool participant determines that the mining services it provides to the mining pool operator are not associated with a contract with a customer, the arrangement is outside the scope of ASC 606. In this case, the mining pool participant would need to determine the appropriate guidance to apply to the arrangement, which could include applying ASC 606 by analogy and distinguishing any such revenue recorded from the entity’s revenue recorded that is directly within the scope of ASC 606.

When a mining pool participant concludes that it is providing services to the mining pool operator (i.e., and not the blockchain) and the mining pool arrangement is a contract with a customer under ASC 606, the mining pool participant will need to perform the revenue standard’s five-step process to determine when, and how much, revenue to recognize.3 The following are specific revenue-related questions to ask regarding mining pool participants in mining pool arrangements:

What performance obligation(s) does the mining pool participant have to the mining pool operator? If the only service the mining pool participant is providing is hash computations, the contract may only contain one performance obligation for the provision of hash computations throughout the contract term.
What is the contract term or the period in which the parties in the arrangement have present enforceable rights and obligations under the contract? If either the mining pool participant or the mining pool operator can terminate the contract at any time without any termination penalties, the contract term may be very short as a result of the lack of enforceable rights for any defined period.
How is the mining pool participant getting compensation for its service, and is that compensation in the form of noncash consideration? If the mining pool participant receives crypto assets from the mining pool operator in exchange for services, the noncash consideration should be measured at its estimated fair value at contract inception. If the contract term is less than 24 hours, a mining pool participant may value noncash consideration by using either a consistent time, or a simple average, each day. For a contract that has a term of less than 24 hours, a mining pool participant is only allowed to value noncash consideration by using either a consistent time or a simple average each day if measuring the noncash consideration in a more granular manner would not create a material difference.
What is the transaction price in the contract, and is it variable or fixed consideration? If the mining pool participant or mining pool operator does not know the amount of consideration that will ultimately be paid out at contract inception, the consideration is all variable. When the term of the arrangement is short, the payments may be made frequently (i.e., paid daily for services performed on the previous day) and the variability of the transaction price often resolves itself quickly, which may eliminate the need to estimate variable consideration for financial reporting purposes.

8.4.1.3 SEC Comments Related to Mining Pool Participants

The following are recent comment-letter excerpts regarding revenue recognition for mining pool participants:

Examples of SEC Comments

Revise your disclosure to indicate how each component of your FPPS [full pay per share] contract consideration and or payment mechanism is calculated. In this regard, we note crypto currency block rewards, transaction fees, and mining pool operator fees.
We note in your revenue recognition policy disclosure that all mining revenue consideration is constrained until the mining pool operator successfully places a block. Please tell us why you believe the block reward portion of your mining revenues cannot be reasonably estimated. In this regard, it appears for FPPS contracts that the only variable at contract inception is the number of hashes you will perform, which is wholly in your control and would appear to be reasonably estimable.
Please tell us, and revise your disclosure in your next amendment to specifically address the following oncerning your mining revenue recognition under ASC 606:
- We note that your contracts are terminable, “at any time by either party.” Please confirm if your contracts are terminable, “at any time by either party without cause and without penalty,” and include this specific disclosure in your next amendment, if true.
- Your consideration of whether each mining pool arrangement is a contract that is continuously renewed and, if so, tell us:
  - Your consideration as to whether the duration of your contracts is less than 24 hours;
  - Whether the rate of payment remains the same upon renewal; and
  - Whether your customer’s option to renew represents a material right that represents a separate performance obligation as contemplated in ASC 606-10-55-42.
- We note that your performance obligation is, “providing computing power in digital asset transaction verification services.” Tell us your consideration for disclosing your performance obligation as, “the service of performing hash computations for the mining pool operator,” or something similar to more precisely and closely align with the promise in your contracts, and include this specific disclosure in your next amendment, if true;
- You disclose that the mining pool in which you participate utilizes the Full Pay Per Share (FPPS) payout method. We further note your disclosure . . . that, “you are entitled to a fractional share of the fixed cryptocurrency award the mining pool operator receives . . . for successfully adding a block to the blockchain,” which appears inconsistent with FPPS where miners receive a fixed payout for each valid share submitted, regardless of whether the pool finds a block. Confirm for us whether you are entitled to compensation whether or not the pool operator receives an award, and revise your disclosure for consistency throughout . . . ;
- We are unable to reconcile your use of the lowest bitcoin price during the day ending midnight UTC with the requirement in ASC 606-10-32-21 to estimate the fair value of noncash consideration on the date of contract inception. Revise your policy to consistently select a single time within the date of contract inception or a simple average during that day. For all periods in your filing, tell us the impact on your revenue recognized by applying this revised policy and provide us your SAB 99 analysis as to whether any of these differences are material.
Tell us how you determined the term of your contracts and the period of service for which the mining pool operators determine your compensation.
You disclose that you are entitled to compensation regardless of whether the pool operator successfully records a block to the bitcoin blockchain, and that you recognize revenue when it is probable that a significant reversal in the amount of cumulative revenue recognized will not occur. Tell us how your accounting policy considered ASC 606-10-25-23 to 25-25, and when during the contract term you recognize revenue.

8.4.2 Proof-of-Stake Blockchains and Staking

8.4.2.1 Proof of Stake

Proof of stake (PoS) is a consensus mechanism in which validators “stake” crypto assets on a blockchain to be selected as a validator, or to attest to the work of other validators for a particular block, in exchange for rewards. Assets staked by a validator may include the validator’s own assets or those of third parties, commonly referred to as delegators. Staked assets may be subject to a lock-up period, the duration and rules of which vary by protocol, during which the assets cannot be withdrawn or otherwise used. A validator will signal its intent to start validating and enter a queue to be selected. Staking mechanisms can take many forms and are continually evolving; generally, however, the larger a participant’s stake and the longer the assets have been staked, the higher the likelihood of selection as the next validator and the higher the staking rewards. Staking allows holders of a particular asset not only to benefit from the price appreciation of the crypto asset but also to earn additional rewards (e.g., new units of the crypto asset), thus increasing the total return on holding the staked assets.

A key difference between PoS protocols and their proof-of-work (PoW) predecessors is the incentive’s structure. In PoW, miners must win a computational race to solve a cryptographic puzzle and validate a new block, thereby securing the network through the energy costs invested in solving the puzzle. By contrast, PoS relies on a penalty mechanism known as “slashing,” wherein a portion of a validator’s staked tokens may be “slashed” (permanently removed from circulation) if the validator acts maliciously or fails to respond when selected to validate. This mechanism helps maintain network integrity without the higher energy costs associated with PoW.

PoS protocols continue to evolve. The rules and mechanics of one PoS network may differ significantly from others; as a result, an entity’s accounting conclusions regarding similar transactions may vary from network to network. In assessing the substance of PoS blockchain transactions, it is important for an entity to consider the specific facts and circumstances of each network, including staking terms, reward structures, and slashing risks.

8.4.2.2 Accounting Issues in Staking Protocols

8.4.2.2.1 Validator Activities

On PoS networks, validator services are a common income-generating activity for validators. When a validator on a network is selected to create/validate a block and the block is successfully produced and confirmed, the network provides a reward to the participants, which is typically executed via a smart contract. The minimum stake (i.e., assets that could be slashed) required for a validator to be selected to provide validation services can come from the validator itself or from third-party delegators.

Delegators are network participants who stake their tokens with validators in the hope of earning validator rewards, as opposed to validating themselves since they most likely do not have the technology or resources to stake on their own. Delegators can stake their assets with the validators of their choice, enabling those participants to participate in the staking activities through a public validator advertised on the network. Validators are selected on the basis of certain information about historical performance, such as uptime and slashing penalties incurred. Staking rewards are paid to the holders of staked assets. When third-party delegators stake assets to a validator’s node, the validator receives a commission that is charged as a portion of the entire reward paid on the delegated assets, generally a commission rate multiplied by the rewards. The amount and payout of the rewards are determined by the protocol, while the commission rate is set by the validator.

8.4.2.2.2 Identifying the Contract With the Customer

In the accounting for validator services, the validator’s share of rewards earned from the network protocol is generally income to the validator. In determining whether this income is within the scope of ASC 606 (on revenue from contracts with customers), an entity should look to the guidance in ASC 606-10-15-3.

In the absence of a signed agreement between validators and the network or the network’s participants, an entity should carefully evaluate whether rights and obligations have been established by the protocol. In some circumstances, the entity may conclude that the customary business practices and protocol of the network create enforceable rights and obligations. Such rights and obligations are protocol-specific; all participants are expected to be aware of the protocol and agree to its conditions when choosing to participate on the network. In such cases, an implied contract may exist for accounting purposes. Understanding the specific protocol on which the entity is transacting is critical to an accounting analysis of the rights and obligations (or lack thereof) established and therefore the basis for a conclusion that a transaction is (or is not) within the scope of ASC 606.

Implied contracts in validation services may exist between a validator and the network or validators and the network participants. (See Section 3.2.8 of Deloitte’s Roadmap Revenue Recognition for considerations related to determining the customer in a contract.) One important consideration related to determining the customer in a validator activity transaction is the party responsible for delivering validator rewards. Some networks issue their tokens “pre-mint,” meaning that all tokens are issued and distributed at network inception, with rewards solely paid from transaction fees; other networks are inflationary and continually issue new tokens. In inflationary networks, a combination of newly issued tokens and transaction fees rewards validators. An entity should carefully consider the source of compensation in determining its customer.

On the basis of the specific facts and circumstances, it is also possible for an entity engaged in validator activities to conclude that the counterparties to these activities do not meet the definition of a customer under ASC 606. In such scenarios, an entity may determine that ASC 606 should be applied by analogy. While the recognition and measurement would not be different under ASC 606, staking services may be classified and presented differently as other revenue besides revenue from contracts with customers. Presenting staking services as other revenue could be consistent with how a miner might separately present PoW block rewards earned as other revenue. See Section 8.4.1 for further discussion.

A validator may stake its own assets to validate transactions on the network; however, as mentioned above, many PoS protocols stipulate that the larger the stake that has been committed, the more likely it is that the validator will be selected and will therefore realize the opportunity to earn rewards. Accordingly, validators benefit when delegators stake tokens with them. Delegators in turn, can participate in the rewards earned through validation activities without the complex technical specifications and associated costs of validation. As a result, a validator will typically have delegators to consider in accounting for validator activities. In these situations, consideration should be given to whether entities that stake their assets provide a security service to the network that is distinct from the validation service itself. In those cases, when delegators stake their assets with a validator, the entity performing the validation activities should evaluate whether it is a principal or agent in delivering the security services associated with delegation. This determination should be based on whether the validator controls the service before it is delivered to the network or its participants.

8.4.2.2.3 Noncash Consideration

Staking rewards are typically delivered in the form of the network’s native token. An entity should evaluate whether these tokens meet the definition of cash or cash equivalents, but many tokens will represent noncash consideration. ASC 606-10-32-21 through 32-23 provide guidance on determining the effects of noncash consideration on determining the transaction price. Noncash consideration is measured at its fair value at contract inception under ASC 606. However, because the number of tokens rewarded for staking activities subject to slashing penalties is typically not known at contract inception, rewards for validator services represent variable consideration. ASC 606-10-32-23 states:

The fair value of the noncash consideration may vary after contract inception because of the form of the consideration (for example, a change in the price of a share to which an entity is entitled to receive from a customer). Changes in the fair value of noncash consideration after contract inception that are due to the form of the consideration are not included in the transaction price. If the fair value of the noncash consideration promised by a customer varies for reasons other than the form of the consideration (for example, the exercise price of a share option changes because of the entity’s performance), an entity shall apply the guidance on variable consideration in paragraphs 606-10-32-5 through 32-14. If the fair value of the noncash consideration varies because of the form of the consideration and for reasons other than the form of the consideration, an entity shall apply the guidance in paragraphs 606-10-32-5 through 32-14 on variable consideration only to the variability resulting from reasons other than the form of the consideration. [Emphasis added]

The settlement amount of staking rewards under the contract represents a form of variability other than the form of consideration. The guidance in ASC 606 on variable consideration requires that an entity estimate the amount of consideration to which the entity will be entitled in exchange for transferring the promised goods or services to a customer and constrain this estimate to the extent that it is probable that a significant reversal in the amount of cumulative revenue recognized will not occur when the uncertainty associated with the variable consideration is subsequently resolved. ASC 606-10-32-14 also requires that an entity update the transaction price at the end of each reporting period to represent faithfully the circumstances present at the end of the reporting period and the changes in circumstances during the reporting period. An entity should therefore carefully evaluate the contract inception date (e.g., upon being selected to perform a specific assignment for the next block by the network, or at some earlier point) and the application of the constraint (see ASC 606-10-32-11 and 32-12) in measuring noncash consideration.

8.4.2.2.4 Delegator Activities

Delegators become party to contractual agreements in the PoS ecosystem, whether explicitly or implicitly, in a number of ways. In the evaluation of the accounting consequences of these transactions, questions can arise regarding whether delegators are providing a service to the network (i.e., enhancing network security by exposing their tokens to slashing penalties for incorrect or malicious behavior by validators) or entering into agreements within the scope of other GAAP. Many PoS tokens and rewards will meet the definition of an intangible asset. (See Section 2.2.2 for criteria related to determining a digital asset meets the definition of an intangible asset.) An entity should consider whether the substance of its delegation activities is akin to loaning its intangible assets to validators in exchange for a return (i.e., an applicable percentage of the staking rewards). See Section 8.2 for a discussion of crypto lending and borrowing transactions. The judgments required in such scenarios can be complex, and entities are encouraged to consult their accounting advisers in determining the appropriate accounting for delegation activities.

8.4.2.2.5 Other Consensus Mechanisms

In addition to PoW and PoS, there are other consensus mechanisms that reward parties securing the network and organizing transactions in similar ways, such as Byzantine fault tolerance (BFT) networks, optimistic rollups, or zero-knowledge rollups. In each case, validators may be known by different names, such as trusted delegates or sequencers, but may be responsible for similar activities such as securing the network or ordering and batching transactions. The activities and reward mechanisms are often similar to those for staking but have unique nuances. Entities engaged in these activities on other types of protocols may make similar accounting determinations even though their facts and circumstances differ. Entities should consult with their accounting advisers in understanding the implications of transacting on a particular blockchain.

Entities should carefully evaluate all staking transactions on an individual basis, since the entity’s accounting conclusions could be affected by various facts and circumstances, including the processes for staking the crypto assets, the services that are being provided, who is involved, and which protocol is used. Because each protocol that allows staking has different staking mechanisms, the accounting could vary from one staked crypto asset to another and from one entity to another depending on its involvement in the staking activities.

Footnotes

For more information about how to determine whether a transaction is a contract with a customer, see Chapter 4 of Deloitte’s Roadmap Revenue Recognition.

See Deloitte’s Roadmap Revenue Recognition for further discussion of the ASC 606 revenue model.

Confidential and Proprietary — for Use Solely by Authorized Personnel

This publication provides comprehensive guidance; however, it does not address all possible fact patterns, and the guidance is subject to change. Consult a Deloitte & Touche LLP professional regarding your specific issues and questions.