Blockchain Software Engineering – by Dr. Andrei Belonogov

Accounting for web3.0 software engineering gets complicated. Two particular areas appear to come up significantly more frequently when  we discuss blockchain software development projects:

1. Differences between legal contract terms, the contract term for  accounting purposes, and the period of performance: 

   • Work may start before the Buyer signs contracts;

   • Contracts may have substantial termination penalties;

   • Performance obligations (POs) may include multiple milestones, and milestones may include numerous POs delivered concurrently.

2.  Payments may be in the form of digital assets:

   • How do companies measure the proceeds of digital assets? 

   • How to measure the fair value of digital assets without an active market? 

   • Does the value of services stated in the contract impact accounting? 

   • How to account for payments made in a different crypto or fiat? 

To correctly measure digital assets received in exchange for services  provided, we can use the process presented in this flowchart:

1. Identify the inception date of the initial contract (and, when applicable, modified contract). Considering:

   1. Customer signature date;

   2. Contract approval dates based on support from informal channels (emails, slack messages, WhatsApp, SMS, etc.);

   3. Delivery date for the first performance obligation (if there is a termination for convenience clause);

   4. Subsequent contract modification dates.

2. Determine the price of digital assets received as of the inception date as:

   1. If, at the contract inception date, there is an active market for digital assets, then we must identify the principal market and use the price sourced from the principal market. Otherwise, we go to step 2(b)

   2. Digital assets that do not have an active market, may still have a value that is reasonably estimable using various valuation techniques. This valuation will likely require the involvement of a third-party valuation expert.

   3. If it is believed that the fair value cannot be reasonably estimated, then we would have to measure the cost basis based on the value of services transferred instead of the value of assets received (because we cannot determine this value). This price then will become a cost basis of digital assets received. However, the determination of prices on services is in itself a complex assessment that involves multiple steps. So what is the most practical way to incorporate these steps under a single roof with the previous steps we went through above? This is the framework we suggest to use:

If services are sold separately to similar customers in similar circumstances, use an observable price of such sales:

[ASC 606-10-32-32] “A contractually stated price or a list price for a good or service may be (but shall not be presumed to be) the standalone selling price of that good or service.”

If an observable price is unavailable, estimate the price using one of the methods described in ASC 606-10-32-33 – ASC 606-10-32-34. The expected cost plus a margin approach would typically determine our service’s standalone selling price. This price will then be divided by the number of units of digital assets received as noncash consideration. 

When the customer makes payments for provided services using a different cryptocurrency or fiat, the Company may follow one of two approaches:

(a) Return consideration received in a form that differs from what was agreed in the contract and request to make the proper settlement.

(b) Accept the different forms of payment and account for this as a contract modification. Depending on specific contract terms, and the timing of modification it may result in either, the difference between the value of the consideration received vs. the value of the consideration that was due under the terms of the original contract:

• Allocated between POs that were satisfied vs. unsatisfied;

• Immediately recognize gain/loss due to changes in the fair value of consideration received related to satisfied POs;

• Recognize the gain/loss on unsatisfied POs consistent with the pattern of revenue recognition of unsatisfied POs.