The Board made several key decisions that could matter well beyond a narrow subset of digital asset holders:

• Include wrapped tokens within the scope of ASC 350-60, which would allow them to be measured at fair value.

• Add illustrative examples to the Codification explaining how the definition of cash equivalents should be applied in determining whether certain stablecoins should or should not be classified as cash equivalents.

• Propose annual disclosures of significant components of cash equivalents that would apply to all entities.

At its April 15 meeting, the Financial Accounting Standards Board discussed staff research and stakeholder feedback on two projects: accounting for transfers of crypto assets and the classification of certain digital assets as cash equivalents.

Wrapped Tokens and ASC 350-60

First, the Board decided to expand the scope of ASC 350-60 to include certain economically similar crypto assets, including wrapped tokens and receipt tokens, under the same fair value model as other in-scope crypto assets. The Board also decided that wrapped tokens should be disclosed separately from the underlying crypto asset.

Stablecoins as Cash Equivalents

Second, the Board considered stakeholder requests for more detailed guidance on when digital assets may qualify as cash equivalents. Rather than revising the definition of cash equivalents in the Master Glossary, the Board chose to move forward with illustrative examples. That approach keeps the existing definition in place while giving preparers more direction on how the Board expects it to be applied. Based on the Board’s discussion, those examples are expected to reinforce a high threshold, including the importance of maintaining at least 1:1 reserves in cash or traditional cash equivalents, and of a direct, on-demand contractual right to a known amount of cash.

New Annual Disclosures of Cash Equivalents

The Board also supported annual disclosure of the significant components of cash equivalents for all entities, extending well beyond the project’s original focus on stablecoins. Those decisions are expected to be reflected in an exposure draft for public comment with a 90-day comment period.

Practical Takeaways

• If your organization holds, for example, WBTC (or other wrapped tokens), those assets could fall within ASC 350-60 and be measured at fair value if the Board’s proposal is finalized. WBTC holdings would need to be disclosed separately from BTC holdings.

• The Board has not yet made decisions on crypto transfer derecognition issues.

• The Board did not change the current accounting policy election framework for cash equivalents. Your organization can elect an accounting policy to classify certain stablecoins as cash equivalents, as long as all applicable requirements set in the glossary definition of cash equivalents are met.

• The proposed annual disclosure of significant components of cash equivalents could affect all entities, not just those with stablecoin-related fact patterns. In that respect, the proposal has a broader reach than the project title might initially suggest.

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 answer the following questions:

• How does DevCo create value for its shareholders?

• What sustainable business models are used by different DevCos?

• What impact does a 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 to the DevCo directly. 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 of time. 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, with the belief 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 , Ethereum , Solana Labs

Conclusion

Strategy determines economics, and economics should determine accounting treatment, not the opposite. 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

This article explains how contractual and inherent to an instrument restrictions affect fair value measurement, disclosure requirements, and the assessment of whether crypto assets are readily convertible to cash.

Relevant Considrerations

Fair Value

Up until last year, entities reporting under US GAAP were not prohibited from applying a discount to the price of securities subject to a contractual sale restriction. Some preparers adjusted the fair value of securities subject to restrictions to reflect such discounts. In contrast, others considered such a discount inappropriate. ASU 2022-03 has now unified practice by requiring that the fair value of an equity security be adjusted only for transfer restrictions inherent to the asset’s unit of account (and that apply to any holder), while no adjustment is needed for restrictions that are specific to the reporting entity [FASB ASC 820-10-55-52, -55-52A]. Contractual restrictions on sale are not part of the unit of account and, therefore, are not considered in measuring the fair value of the instrument. Although ASU 2022-03 specifically discusses equity securities, it is generally considered appropriate to apply this guidance by analogy, including to crypto assets subject to restrictions.

Even though ASU 2022-03 limits the scope of disclosure requirements to equity securities subject to contractual sale restrictions, the same disclosures are required for crypto assets subject to contractual sale restrictions [FASB ASC 350-60-50-6], including:

1. The fair value of equity securities subject to contractual sale restrictions is reflected in the balance sheet.

2. The nature and remaining duration of the restriction(s)

3. The circumstances that could cause a lapse in the restriction(s)

Further, entities should provide similar disclosures for any material balance of other digital assets subject to contractual sale restrictions, even if those assets are neither equity securities nor crypto assets within ASC 350-60.

Readily Convertible to Cash

Contractual sale restrictions are also relevant to whether assets are “readily convertible to cash”. Under this guidance:

”Shares of stock in a publicly traded entity to be received upon the exercise of a stock purchase warrant do not meet the characteristic of being readily convertible to cash if both of the following conditions exist:

• The stock purchase warrant is issued by an entity for only its own stock (or stock of its consolidated subsidiaries).

• The sale or transfer of the issued shares is restricted (other than in connection with being pledged as collateral) for a period of 32 days or more from the date the stock purchase warrant is exercised.”

[FASB ASC 815-10-15-131]

However, ASC 815-10-15-132 explicitly prohibits applying this guidance by analogy. Thus, contractual sale restrictions do not disqualify crypto assets from being considered readily convertible to cash.

Accordingly, embedded derivatives referencing crypto assets are not affected by such restrictions, although their initial and subsequent measurement will follow fair value guidance, which incorporates inherent restrictions.

Thus, the identification and recognition of embedded derivatives for tokens receivable/payable are not affected by restrictions on the transfer of tokens. But the fair value measurement (initial and subsequent) might require an adjustment to account for the effects of restrictions inherent to the underlying tokens.

Practical Implications for Token Fair Value Measurement

When measuring the fair value of token compensation liabilities or tokens receivable, entities should consider restrictions on sale or transfer and adjust the fair value when the restrictions are inherent to the asset. This occurs when:

• The lockup feature is embedded directly in the token’s smart contract or code base

• The restriction exists because the token has not yet been created, issued, or generated

These restrictions are considered inherent to the asset based on its unit of account.

However, when tokens are locked up in a separate smart contract (that is, when an authorized account or program deposits tokens into a smart contract that is not part of the token’s own code base), such restrictions are not inherent to tokens and should be viewed as entity-specific contractual restrictions. Hence, entities need NOT account for such restrictions when measuring the fair value of tokens receivable or payable.

Further, when measuring the fair value of token compensation liabilities, entities should not make adjustments for vesting or lockup provisions specific to an individual award.

Conclusion

A clear distinction must be made between restrictions that are inherent to the digital assets themselves (that is, technological restrictions) and contractual restrictions that apply only to an individual entity (that is, legal restrictions). Only restrictions inherent to the asset’s unit of account affect its fair value. Contractual restrictions do not affect fair value, nor do they prevent crypto assets from being considered readily convertible to cash.

Acquihiring is a common strategy used by companies seeking access to highly skilled talent, particularly in the tech space. An acquihiring transaction is a transaction in which an acquirer obtains control of a target company primarily to gain access to its workforce rather than its products, customers, or processes. These transactions are most common in technology and other knowledge-intensive industries where highly specialized teams are difficult to recruit organically.

In most acqui-hiring transactions, the acquired entity ceases operations shortly after the acquisition date. Employees are integrated into the acquirer’s organization, and the target’s products and services are discontinued, absorbed, or deprioritized. The principal strategic benefit is the ability to acquire a fully formed, highly specialized team within a compressed timeframe.

Although the transaction value is typically driven primarily by the acquisition of human capital, current guidance frequently results in these transactions being accounted for as business combinations, with workforce-related value subsumed into goodwill and prohibited from separate recognition.

This paper explains the economic characteristics of acqui-hiring, outlines the applicable accounting framework, and highlights structural tensions in how existing guidance captures these transactions. It also discusses common structuring variations, including reverse acqui-hiring, and identifies areas where accounting outcomes may be driven more by technical form than by economic substance.

Economic Substance of an Acqui-hiring Transaction

From an economic perspective, the consideration transferred in an acqui-hiring transaction is paid primarily for the following components:

• Contractual workforce-related rights, such as employment agreements, retention arrangements, and non-compete clauses

• Non-contractual workforce-related value associated with an assembled team and its collective expertise

• Intellectual property, including developed technology, in-process research and development, or internal-use software

Any existing business processes are often incidental to the transaction and are not expected to continue in their pre-acquisition form.

Applicable Accounting Models

Under US GAAP, an acqui-hiring transaction must be accounted for using one of two models:

• The acquisition method for business combinations

• The cost accumulation model for asset acquisitions

The determination of the applicable model is governed by whether the acquired set meets the definition of a business under ASC 805. The accounting framework does not provide a separate model for transactions primarily motivated by workforce acquisition. As a result, acqui-hiring transactions are forced into one of these two existing models.

Determining Whether an Acqui-hire Is a Business

Under FASB ASC 805, Business Combinations, the buyer should determine whether features of the acquired set indicate that a new business needs to be integrated with the acquirer’s existing business. This determination is based on the two-step process designed to assess whether the FASB’s formal definition of a business in ASC 805-10-55-3A through 805-10-55-9 has been met in the context of a set.

Step 1: Concentration of Fair Value Test.

The first step evaluates whether substantially all of the fair value of the gross assets acquired is concentrated in a single identifiable asset or a group of similar identifiable assets. If this test is met, the acquired set is not a business.

In acqui-hiring transactions, a significant portion of the transaction value is often concentrated in the assembled workforce. However, because an assembled workforce is not an identifiable asset for purposes of ASC 805, it is excluded from the concentration test. As a result, transactions in which workforce-related value clearly dominates the economics may nonetheless fail the concentration test.

Step 2: Business Definition (Inputs and Processes) Test.

If the concentration test is not met, the acquirer must assess whether the acquired set includes both inputs and substantive processes that together have the ability to create outputs.

“A business is an integrated set of activities and assets that is capable of being conducted and managed for the purpose of providing a return in the form of dividends, lower costs, or other economic benefits directly to investors or other owners, members, or participants.”

[FASB ASC 805-10-55-3A]

While a workforce alone does not constitute a substantive process, in practice, the combination of a workforce and intellectual property often leads to the conclusion that a substantive process exists. In acqui-hiring transactions, however, these processes are frequently economically insignificant and are not expected to generate outputs independently post-acquisition.

Accounting Outcomes

Under both models, an acquirer typically recognizes additional assets that are not present on the balance sheet of the target. This is because the transaction provides evidence that internally generated intangible assets of the target do actually exist and has external value supported by empirical evidence.

Accounting standards require accounting to reflect the financial position and changes thereto from the perspective of a general user of financial statements. From the perspective of this general user, the nature of the set acquired, rather than its intended purpose, determines the transaction accounting treatment.

For the same reason, the fair value of individual assets (which is important for both types of transactions) is determined based on market participant assumptions, hence, specific buyer’s intentions regarding the use or abandonement of an asset do not change the fair value measurement, because other market participants might be willing to pay for the asset.

Business Combination Accounting

In a business combination, the acquired set is a business, and a business is more than just a sum of its individual parts. Thus, identifiable assets and liabilities are recognized at fair value as of the acquisition date, and any excess of the consideration transferred over the fair value of identifiable net assets is recognized as goodwill.

Goodwill arises because the transaction price is negotiated for a going concern. Economically, goodwill represents the present value of expected abnormal returns that exceed the normal return on identifiable net assets. These returns only exist because the assets are already organized into a functioning business.

Transaction costs are expensed as incurred because capitalization as part of cost of identifiable assets would result in a cost basis different than the fair value of individual assets

Asset Acquisition Accounting

In an asset acquisition, the acquired set is not a business. Therefore, the set is just the sum of individual assets and liabilities acquired, and nothing more than that. Hence, standard cost accumulation model is followed where we assign total cost (including liabilities assumed and transaction costs) of transaction to all assets acquired. based on their relative fair values. No goodwill is recognized.

Assembled Workforce Accounting

Business Combinations

ASC 805 prohibits the separate recognition of an assembled workforce in a business combination [ASC 805-20-55-6]. An assembled workforce does not meet the definition of an identifiable intangible asset because it is not separable and does not arise from contractual or legal rights.

As a result, its value cannot be measured separately from the overall business and is instead included in goodwill.

The accounting framework intentionally treats assembled workforce differently from other intangibles in a business combination. Goodwill represents the residual value of the acquired business after identifiable assets and liabilities are recognized, and the value attributable to an assembled workforce is included in that residual.

Two examples of acquihiring transactions accounted for as business combinations:

• Glu Mobile, Inc. acquired Dairy Free Games, Inc., a small mobile game studio, for $2m cash as discussed in the filing available here. The deal was treated as a business combination. Identified intangibles included in-process R&D for the game under development. About $0.6 million was recorded as goodwill attributable primarily to synergies and assembled workforce.

• Acquisition of MediaCrossing, Inc. by Kubient that was explicitly identified as the acqui-hire in the buyer’s Form 10-K. Although the legal form was an Asset Purchase Agreement (available here), Kubient concluded that the acquired set constituted a business and a deal was accounted for as a business combination. The goodwill was attributed primarily to business reputation, assembled workforce, and anticipated synergies.

Asset Acquisitions

In an asset acquisition, an assembled workforce may be recognized as an identifiable intangible asset because the transaction price provides observable evidence of value. The assembled workforce is measured by allocating transaction price among assets acquired based on their standalone fair values. The standalone fair value of the assembled workforce is typically determined using a replacement cost method. The allocated cumulative costs assigned to the assembled workforce are amortized over expected useful lives.

An example of acquihiring transaction accounted for as an asset acquisition can be found in Form 10-K of Maximus, Inc. Maximus reports that on February 14, 2024, it acquired part of an IT vendor that had been providing services to the company. Cash consideration was 18.0 million dollars. Maximus states that almost all of the consideration ($17.9m) was allocated directly to the most significant asset, the assembled workforce, which was recognized as an intangible asset and amortized over eight years.

How to Appropriately Account for Employee Payments and Other Transactions Separate from Acquihiring?

Careful evaluation is required to distinguish consideration transferred for the acquired business or assets from payments related to separate transactions, including compensation for post-acquisition services.

Amounts attributable to pre-acquisition services required to consummate the transaction are included in the purchase price.

Amounts attributable to post-acquisition services1, retention arrangements, or continued employment are recognized as compensation expense in the post-acquisition financial statements. We should also note that if the legal documentation of the deal specifies that a portion of contingent consideration paid is linked to the permanence of the seller acting in its capacity as an employee of the combined entity, this portion should be excluded from the transaction price and accounted for as compensation.

In acqui-hiring transactions, interdependencies between transaction consideration and compensation arrangements can complicate this analysis, particularly in reverse acquihiring transactions.

EXAMPLES

Payments treated as a part of the transaction price:

• Payments required to consummate the transaction

• Replacement awards attributable to pre-transaction service

• Earnouts contingent on acquired business performance or nonemployee conditions

• Severance payments to terminated employees

• Replacement of existing stock awards based on the law or pre-existing obligations

• Stock options vested upon a change in control.

Payments treated as compensation expense:

• Fees paid under the transition service agreements (in acquihiring such agreements are less common and typically narrower in scope than in traditional acquisitions)

• Replacement awards attributable to post-transaction service

• Voluntary replacement of existing stock awards that expire upon a change in control

• Excess of the fair value of the replacement awards over the fair value of the acquiree’s award for which employees have rendered the required services as of the acquisition date

• Earnouts contingent on continued employment or retention metrics

What is Reverse Acquihiring?

In addition, there is also what is generally known as “reverse acquihiring”. In a reverse acqui-hiring structure, the acquirer does not acquire the target entity. Instead, it licenses technology or intellectual property and hires employees directly through individual employment agreements.

The target entity may be dissolved or continue to exist, but with limited ongoing operations. For the acquiree, this transaction is not a liquidity event; however, payments for the licensing of existing technology are intended to provide fair compensation to existing investors (and employees who do not receive an employment offer).

These arrangements are generally accounted for as multiple separate transactions rather than as a business combination. No assembled workforce or goodwill is recognized. Payments for employment are treated as compensation, and licensing arrangements are accounted for under the applicable guidance for intangible assets.

Great examples of reverse acquihiring deals were discussed in the following Substack post:

Stack Trace

The Rise of Reverse Acquihires

Last week, Google paid Windsurf $2.4 billion. Not to buy the company, but to license its technology and hire the founders plus their core team. Within days, most Windsurf employees found themselves stranded at a leaderless company until Cognition swooped in with an acquisition…

Read more

9 months ago · 2 likes · 1 comment · Jack Arenas

What Features of Acquihiring are not Reflected in Existing Accounting Models?

Overall, asset acquisition accounting is suited for a deal with no expectation of integrating the new business into the existing business. On the other hand, a business combination is suited to a deal where integration is expected (or at the very least possible). However, the economic features of an acquihiring deal do not always align with this view. In particular:

1. The mere presence of an assembled workforce is traditionally viewed as an indicator that the acquired set includes a substantive process, hence, meets the definition of a business. Yet, an acquihiring transaction is distinct from other acquisitions specifically because the target’s substantive processes (if any) are typically considered insignificant and even irrelevant to the deal motivation and the transaction price calculation. If the acquired set does not include an economically meaningful component related to such a process, it might be argued that the transaction does not involve a business combination and should instead be treated as an asset acquisition in the general case.

2. In an acquihiring transaction, the transaction value is often concentrated primarily in an assembled workforce. This effectively provides additional assurance regarding the value of the assembled workforce acquired, similar to that in an asset acquisition (which is the underlying rationale for recognizing assembled workforce intangibles in an asset acquisition but not in a business combination transaction).

3. The differentiation between accounting for a business combination and an asset acquisition is often driven by where the transaction value is concentrated. However, because ASC 805-20-55-6 does not permit separate recognition of the assembled workforce in a business combination, the screen test does not consider the concentration of value in this asset in determining whether the transaction should be treated as an asset acquisition or a business combination.

4. However, under the existing guidance, the acquisition strategy increases the likelihood that a transaction will be classified as a business combination and that the value of the assembled workforce will be assigned to goodwill.

5. Additionally, normally, employee compensation arrangements are accounted for separately from transactions. However, in acquihiring, interdependencies might exist between the transaction price and compensation, which may not be resolvable using traditional accounting methods. This is particularly true for reverse acquihiring, where employment and licensing arrangements are recognized on a per-contract basis.

Conclusion

Although existing guidance provides a reasonably practical framework, its application to acqui-hiring transactions can produce results that emphasize technical form over economic substance.

As acqui-hiring continues to be a common transaction strategy, careful judgment and robust documentation are required to ensure that accounting conclusions appropriately reflect the nature of the acquired set and the drivers of transaction value. If your team is involved in an acqui-hiring transaction, please reach out to share your experience and observations.

Frequently Asked Questions About Acqui Hire Accounting

If the startup has no customers or revenue, can it still be a business?

It depends. An acquired set does not need to have revenue or customers to meet the definition of a business, provided it includes inputs and substantive processes capable of producing outputs, an organized workforce, and an input that it can develop and convert into an output.

Does the presence of employees automatically mean the set is a business?

No. A workforce alone does not constitute a substantive process under ASC 805. While employees are often essential to operations, their mere presence does not demonstrate the existence of an organized process capable of producing outputs. To qualify as a business, there must be evidence of structured activities, workflows, or operating systems that extend beyond individual employee skills.

Can we record an assembled workforce intangible even if the purchase agreement does not mention it?

Yes. In an asset acquisition, recognition is based on the substance of the acquired asset rather than the contractual labels used. If the acquired set includes an assembled workforce and that workforce has measurable value, it may be recognized as an intangible asset, even if it is not explicitly named in the purchase agreement. The existence of an arm’s-length transaction provides evidence of value, and the asset is measured based on relative fair value.

Do the accounting treatment of transaction costs differ between business combinations and asset acquisitions?

Yes. In a business combination, transaction costs are expensed as incurred and are not included in the purchase price. In contrast, in an asset acquisition, transaction costs are capitalized into the cost of the acquired assets.

How do companies account for non-compete clauses acquired in acqui-hiring transactions?

A non-compete agreement is a contractual right that restricts an individual or entity from engaging in specified competitive activities for a defined period and geographic area. When obtained in connection with an acqui-hiring transaction, a non-compete may represent an identifiable intangible asset if it arises from contractual or legal rights.

In acqui-hiring arrangements, non-compete clauses are often included to limit founders' or key employees' ability to compete with the acquirer after the transaction. From an accounting perspective, the presence of a non-compete does not, by itself, determine the accounting treatment; rather, the analysis focuses on whether the agreement represents an identifiable intangible asset and has measurable economic value.

If a non-compete meets the definition of an identifiable intangible asset, it is recognized regardless of whether the transaction is treated as a business combination or an asset acquisition. The difference lies in measurement. In a business combination, the non-compete is measured at fair value as of the acquisition date, with any residual consideration recorded as goodwill. In an asset acquisition, the total consideration is allocated to the acquired assets based on relative fair values, and no goodwill is recognized.

In practice, non-compete clauses in acqui-hiring transactions are often not separately recognized. This is because their economic value is frequently limited or highly subjective, particularly when enforceability is uncertain. Valuation depends heavily on factors such as legal enforceability, geographic and temporal scope, and the likelihood that the restriction would meaningfully prevent competitive behavior.

Recent legal developments further affect this analysis. Although the Federal Trade Commission issued a 2024 rule proposing a broad ban on non-compete agreements, it was subsequently vacated and is not in effect. As a result, enforceability remains governed by state law, many of which significantly restrict or prohibit non-competes for certain categories of workers. These limitations often reduce or eliminate the practical value of non-compete agreements.

Accordingly, while non-compete clauses may meet the technical criteria for recognition as intangible assets, they are frequently concluded to have little or no separately measurable value in acqui-hiring transactions. Where recognized, their valuation requires significant judgment and is highly sensitive to assumptions regarding enforceability, scope, and duration.

Ethereum’s EVM has no native support for decimals or fractions, so all ERC20 tokens are represented as whole numbers. Tokens define their precision through the decimals field. Decimals split a token into minimal units, and the EVM does all calculations using whole numbers of these units. Using just two decimals is often too coarse for on-chain fees, transfers, and DeFi integrations. Stablecoins, therefore, choose the number of decimals to balance usability and precision. Six decimals (for example, USDC, PYUSD) and 18 decimals (for example, DAI) are common.

PYUSD uses 6 decimals (see the contract implementation), meaning 1 PYUSD is actually 1,000,000 units on chain. When someone wants to mint 300 million PYUSD, they must pass an integer equal to:

300 000 000 × 10^6 = 300 000 000 000 000 units

It is easy to miscount zeros or mix up the expected unit format, especially when decimals differ across tokens or internal tools show raw numbers. Paxos described the $300T mint as an internal technical error during an internal transfer, and public analysis indicates it was essentially a decimal or unit mismatch – a fat finger error on the integer amount required for minting.

There are a few simple controls that could prevent this kind of mistake:

1. Review and approval with proper segregation of duties. Each mint should be reviewed by another person who reconciles the amount to the USD collateral received.

2. Using a multi-signature wallet for the minting process, where multiple approvers must sign before minting, would be even stronger.

3. A minting interface that requires dual confirmation. The operator should enter the mint amount in both PYUSD (human-friendly) and raw on-chain units (6 decimals), with the system calculating and displaying both clearly before approval. The confirmation screen should explicitly show something like: “You are about to mint 300 000 000.00 PYUSD (300 000 000 000 000 units).”

A few simple checks and better tooling would make errors of this scale nearly impossible and strengthen trust in the system.

US regulators have begun paying closer attention to dollar-backed stablecoins and their role in financial reporting. On April 4, 2025, the SEC issued a staff statement on “covered stablecoins”. The statement defined “covered stablecoins” as crypto assets designed to maintain a stable value relative to the US dollar, backed by low-risk and readily liquid reserves, and redeemable 1:1 for cash. Although this statement addresses securities law rather than accounting classification, the characteristics it highlights align closely with the existing US GAAP definition of cash equivalents.

Later that year, on October 29, 2025, the FASB added a narrow project to its technical agenda to determine whether certain digital assets, including stablecoins, can be classified as cash equivalents.

Our review of current practice, risk factors, and individual stablecoin designs has led us to three central conclusions:

• First, only a narrow group of fiat-backed stablecoins can reasonably meet the criteria for cash equivalents. These tokens must hold high-quality liquid reserves, offer clear and enforceable redemption rights, maintain sufficient market depth relative to the holder’s position, and exhibit a price history largely free from meaningful depeg events.

• Second, even when these conditions are satisfied, the classification remains an accounting policy choice. Management should evaluate each specific instrument separately, document the basis for its judgment, and revisit that conclusion if the facts change. Management should maintain clear documentation that supports the selected classification. Best practices include using standard checklists to ensure all necessary facts and circumstances are considered.

• Third, many stablecoins do not qualify. Tokens supported by opaque or risky reserves, decentralized or crypto-collateralized designs, or algorithmic mechanisms exhibit risk and liquidity profiles inconsistent with cash-equivalent treatment. Recent court orders freezing hundreds of millions of dollars connected to TrueUSD-related reserves show how governance or legal issues can quickly impair convertibility.

Subscribe now

Given these factors, only a small group of well-regulated, fiat-backed stablecoins, such as USDC, and a limited set of peers are likely to be treated as cash equivalents in the near term. Even then, classification should be supported by position size limits, active monitoring of reserve composition and legal structure, and transparent disclosure. For example, a practical guideline for entities could be to set their position size limits to no more than 5% of the stablecoin’s average daily trading volume over the past 30 days. This provides a concrete metric to ensure that a significant liquidation of their position can occur without adversely impacting the market.

What Do Regulators Say About Stablecoins as Cash Equivalents?

On April 4, 2025, the SEC issued a staff statement describing key attributes of “covered stablecoins.” The statement explains:

“Covered Stablecoins are crypto assets designed and marketed for use as a means of making payments, transmitting money, or storing value. They are designed to maintain a stable value relative to USD and are backed by USD and/or other assets that are considered low-risk and readily liquid so as to allow a Covered Stablecoin issuer to honor redemptions on demand.[6]”

[“Statement on Stablecoins”, SEC]

This description prompted market commentators, including Bloomberg and other analysts, to conclude that dollar-backed stablecoins offering one-for-one redemption and immediate convertibility might qualify as cash equivalents under US GAAP. These discussions ultimately contributed to the question being added to the FASB’s technical agenda.

At its October 29, 2025, meeting, the FASB staff presented an overview of current guidance and stakeholder feedback. Views were mixed regarding whether to revise the definition of cash equivalents or develop stablecoin-specific rules. Several stakeholders supported a more principles-based update that would reflect assets without stated maturity, address the treatment of certificates of deposit, and clarify how the definition applies to money market funds.

The emerging direction favored refining the existing definition rather than creating an entirely new category for digital assets. Still, the project remains at an early stage, and the board has not yet indicated the final form of its guidance.

To understand how current practice compares to the formal definition, we conducted a brief review of technology sector Form 10-K filings:

We reviewed a small sample of technology-sector filings to understand which types of instruments public companies include in cash equivalents. The summary below reflects the results.

Across these filings, companies consistently included the same categories of instruments in cash equivalents:

• Bank Deposits. Demand deposits and certificates of deposit were consistently treated as cash equivalents. This was true even for deposits with no stated maturity, since the defining characteristic was the immediate availability of funds.

• Short-Term Debt Securities. Holdings of U.S. Treasury bills, government agency notes, high-grade commercial paper, and similar short-term instruments (maturing within three months) were included as cash equivalents. For example, Alphabet classified highly liquid government and corporate notes maturing within ninety days as cash equivalents. Cisco included short-term commercial paper, treating these instruments as near-cash due to quick maturity and low risk.

• Money Market Funds. Most companies list investments in open-ended money market funds as cash equivalents, often limiting inclusion to AAA-rated funds. Despite lacking a stated maturity, companies relied on their stable value, same-day liquidity, and diversified portfolios to support inclusion as cash equivalents.

Instruments reported within the “Cash and cash equivalents” line on the balance sheet generally share two qualities tied to their short duration:

• Minimal credit risk

• Insignificant interest rate risk

Instruments that did not meet the maturity, liquidity, or risk criteria were reported elsewhere on the balance sheet. Longer dated marketable securities, for example, appeared within “short-term investments” or “marketable securities” rather than within cash equivalents.

Definition of cash equivalents

Having reviewed industry practice and regulatory guidance, we next examine the formal definition of cash equivalents. Under US GAAP, the definition of cash equivalents is set out in the FASB ASC. Cash equivalents are defined as short-term, highly liquid investments that meet both of the following conditions:

1. They are readily convertible to known amounts of cash, and

2. They are so close to maturity that they pose an insignificant risk of changes in value due to interest-rate movements.

In practice, this definition is usually applied using the following benchmarks:

• Original maturity of three months or less.
  Original maturity is measured from the date the reporting entity acquires the instrument to its contractual maturity date. A three-month Treasury bill qualifies as a cash equivalent. A three-year note purchased with three months remaining also qualifies. A three-year note that has been held for three years does not suddenly become a cash equivalent just because there are only three months left until maturity.

• Investment nature.
  Cash equivalents are investments purchased to earn a small return on surplus cash without exposing that cash to material loss. They are not operating receivables or other non-investment balances.

• Limited exposure to interest rate risk.
  The yield on the instrument can be fixed or variable, but changes in market interest rates during the holding period should not be expected to cause a material change in the amount of cash the entity would receive if it sold or redeemed the instrument before maturity.

• Active market and known exit value.
  The investment should be tradable in an active market or redeemable on demand so that the entity can quickly obtain cash at a reasonably predictable amount. Instruments that are thinly traded, subject to gates, or exposed to significant discounts under stressed conditions generally do not qualify.

It is important to distinguish between:

• Any change in fair value, and

• Changes in value that arise from interest rate movements.

The FASB ASC Glossary focuses on the latter. An instrument can still qualify as a cash equivalent even if its carrying amount changes over time, for example, as a discount accretes, as long as the only reasonably expected source of variability is that mechanical unwind and any additional variability is clearly immaterial.

Economic purpose also matters. Cash equivalents are typically used to invest idle cash in very low-risk instruments that can be converted into cash on demand for a predictable amount (as per the basis for conclusion in FASB Statement 95). They sit at the very short-duration, very high-liquidity end of the investment spectrum. That is why they are grouped together with cash on the balance sheet and used directly in liquidity analyses that compare “cash and cash equivalents” to current and near-term obligations.

What risks affect the value of cash equivalents?

When evaluating whether an instrument qualifies as a cash equivalent, the relevant question is not “is this an investment” but “what risks can materially affect its value or convertibility.” The main risk categories are:

• Interest rate risk.
  The impact of changes in market interest rates on the security's value.

• Liquidity risk, which has two components:

  • Market liquidity risk refers to the risk of forced sales at prices below observable levels when markets are thin or volatile, for example, during large redemptions or portfolio rebalancing.

  • Funding liquidity risk is the risk that there is not enough liquidity to redeem the instrument in the required size or timeframe.

• Credit risk, which also has two components:

  • Default risk is the probability that an issuer will fail to meet payment obligations in full and on time. Higher default risk generally leads to greater price volatility and lower liquidity.

  • Downgrade risk is the risk that the issuer or the instrument is downgraded by rating agencies, which can trigger forced sales at depressed prices.

These risks drive the classification question. If any of them could reasonably result in a material loss of value or a material delay in obtaining cash, the instrument usually does not belong in cash equivalents.

What risk mitigation strategies exist to maintain the stable value?

Traditional cash equivalent portfolios try to maintain stable value through a combination of structural and risk management techniques:

• Duration management. Interest rate risk can typically be addressed by limiting the portfolio's weighted-average maturity or duration. Shorter maturities reduce sensitivity to rate changes.

• Credit quality monitoring. Default and downgrade risks are managed through the internal credit rating process and due diligence.

• Diversification. Most of the risks we identified can be mitigated via diversification. Avoiding excessive concentration in any single issuer, sector, or instrument type.

• Short tenor and maturity laddering. Short average maturities and staggered maturity dates help ensure that cash is available ahead of liability due dates.

For most fiat-backed stablecoins, token-level interest rate risk is not directly relevant, as the tokens are usually redeemable on demand at par in fiat currency. However, the reserves backing those tokens carry interest rate and credit risk, and poor reserve management can manifest as liquidity or credit events that threaten the stablecoin’s ability to maintain its peg.

Applying these concepts to stablecoins

Maturity considerations

Maturity is usually measured from the instrument's acquisition date to its contractual redemption date, or to the expected redemption date if early redemption features are substantive.

For ordinary debt instruments, longer maturity generally means higher yield and greater sensitivity to interest rate shocks. That logic underpins the conventional “three-month” threshold used in practice: shorter maturity is a proxy for insignificant interest rate risk. The three-month mark also aligns with quarterly reporting cycles, which probably explains its adoption rather than any deep economic principle.

From an economic standpoint, it is more helpful to focus on how much the instrument’s value can move in response to reasonably possible interest rate changes and whether that potential movement is clearly immaterial.

For example, a simple duration-based analysis shows that a one percentage point change in interest rates typically causes less than a 0.5 percent price move for securities with maturities of roughly 150 days or less.

Below is a table that shows the impact of a 1% increase in the market interest rate on the value of instruments with different maturities and original yields. We calculate the price impact as follows:

Percent price change ≈ Duration / (1 + Yield to Maturity) × Δ Yield to Maturity

Under a 90-day threshold, the range is often near 0.2-0.3 percent, suggesting that the exact cutoff is somewhat arbitrary.

Stablecoins behave differently. Most fiat-backed stablecoins have no stated maturity and are redeemable on demand. In effect, the “maturity profile” of a stablecoin aligns with the holder’s own liquidity needs, since the token can be converted to fiat in a time frame that is usually measured in days. As a result, accounting maturity is generally not a helpful factor for stablecoin classification, and interest rate risk is also not relevant.

The key questions we need to ask include:

• How quickly can the holder convert the token into fiat under normal conditions?

• Under what circumstances can redemption be delayed or denied?

• Is there a substantial risk that reserves might not be sufficient to honor redemptions?

Share

Liquidity Considerations

Guidance and practice agree that cash equivalents must be “readily convertible” to cash. As PwC notes:

“The term ‘readily convertible’ implies that an investment must be convertible into cash without an undue period of notice and without incurring a significant penalty on withdrawal… Cancellation clauses, termination fees or usage restrictions might affect the redemption amount and create a more than insignificant risk of change in value.Where the counterparty to a short-term investment experiences financial problems, there may be some doubt over its ability to fulfil the agreement’s requirements. In these instances, the investment should not be classified as a cash equivalent, because there is a risk that the instrument will not be readily convertible or that the redemption obligation will not be met.”

[PwC]

In practice, many analyses of cash equivalents focus heavily on maturity and credit quality, treating liquidity as almost an assumption. For stablecoins, that shortcut is dangerous. Entities must explicitly evaluate both:

• Depth and resilience of secondary market trading, and

• Practical ability to redeem through the issuer or authorized intermediaries.

A stablecoin might trade at or near one dollar most of the time, yet still be unsuitable as a cash equivalent if the market cannot absorb the entity’s position without significant slippage.

As a suggested guideline, we recommend that entities set internal exposure limits for instruments classified within “cash equivalents.” In particular, a stablecoin should generally not be included in cash equivalents if the reporting entity’s position exceeds a modest share of the token’s typical trading volume. We would suggest avoiding classifying stablecoin holdings as cash equivalents if the entity holds more than 5 percent of the lowest daily trading volume observed over the past 30 days. This type of limit needs to be tailored to the markets and venues the entity actually uses. Regular monitoring will help capture any significant changes in market conditions and ensure that position limits remain appropriate.

The recent experience of our selected stablecoins illustrates this:

For example, a liquidation of approximately $3.25 million of PYUSD might, at certain points in the last 30 days, have represented more than 5 percent of daily trading volume (as per CoinGecko1). In that scenario, classifying the entire position as cash equivalents could overstate the cash that could be realized quickly without a meaningful price impact.

Credit Rating Considerations

For traditional debut securities, credit ratings and expected rating changes may affect liquidity. The lower the credit rating, the lower the liquidity available for the instrument. A change in a credit rating might trigger the forced closure of positions held in this asset.

Stablecoin issuers do not have ratings assigned by credit rating agencies. Instead, S&P initiated “stablecoin stability assessment ratings” published since 2024. Below are some notable ratings:

• USDC - 2 Strong (published 12/19/24)

• USDT - 4 Constrained (published 12/3/24)

• TrueUSD - 5 Week (published 11/14/25)

S&P methodology rates stablecoins based on the following areas of assessment:

• Asset assessment

• Governance

• Legal and regulatory framework

• Redeemability and liquidity

• Technology and third-party dependencies

• Track record

We wanted to note one additional point about the effect of third-party guarantees, such as Coinbase’s promise to all retail users to redeem USDC at a 1:1 ratio. We believe that the value of USDC relies heavily on Coinbase’s adherence to this promise. A change in Coinbase’s credit rating or its potential decision to no longer guarantee USDC redemptions at a 1:1 ratio might significantly affect USDC’s peg stability.

Other Considerations

US GAAP does not explicitly require conversion costs to be insignificant for an investment to qualify as a cash equivalent. However, the line item “cash and cash equivalents” is commonly used in liquidity analysis by comparing it directly with liabilities of various maturities. If significant fees or operational frictions apply when converting a stablecoin to fiat, the amount of value truly available to meet short-term obligations may be meaningfully lower than the reported balance.

For that reason, it is reasonable to consider:

• typical and worst-case conversion fees,

• slippage from exiting the position in realistic market sizes, and

• any operational or regulatory delays in accessing fiat.

Even though these factors are not a part of the existing definition of cash equivalents in accounting authoritative guidance, they are consistent with the economic purpose of the cash equivalents category.

Overall, cash equivalents should be considered a subset of investments with the shortest effective maturities and the highest reliable liquidity. They should be redeemable for cash almost immediately, and until redemption, there should be an active market or a robust redemption channel that allows the instrument to be converted to a known amount of cash with minimal uncertainty.

What is the appropriate accounting treatment of specific stablecoins?

Stablecoins are typically issued by special-purpose entities that hold financial assets as collateral and owe token holders a fixed claim in a reference asset, often US dollars, at a specified one-for-one redemption ratio. In most designs, only institutional customers or certain intermediaries can redeem directly with the issuer, while retail users and many corporate holders rely on trading in the secondary market or on third-party guarantors, where they exist.

From an accounting standpoint, a stablecoin is more likely to qualify as a cash equivalent when:

• Reserves are held in cash and very high-quality liquid assets,

• Those reserves are legally separated for the benefit of token holders,

• The issuer has a consistent track record of honoring redemptions, and

• The token trades with tight spreads and limited depeg episodes in stressed markets.

In those cases, the stablecoin can be viewed as economically similar to a money market fund share or a very short-term deposit and may be treated as a cash equivalent, subject to the entity’s accounting policy.

Under current guidance, reporting entities can already elect to include qualifying stablecoins in cash equivalents if the tokens satisfy the authoritative definition criteria. Since designs differ significantly across issuers, management must evaluate each stablecoin individually.

To ensure consistency in this evaluation and appropriateness of conclusions, management should address several points:

1. Collateral Quality: Assess the specific assets backing the stablecoin, ensuring they are not exposed to a significant risk of decline in value. Assess whether the issuer can pledge or lend these assets.

2. Redemption Rights: Evaluate whether holders have an enforceable right to redeem tokens at par, including redemption venues, restrictions, and third-party guarantees present.

3. Market Liquidity: Evaluate the level and stability of trading volumes of the stablecoin analyzed.

4. Price Stability: Examine the frequency, magnitude, and duration of past depeg events, including the issuer’s actions in response to prior stress events, and whether the mechanisms worked as intended.

These steps provide a practical framework for evaluating whether a stablecoin meets cash-equivalent characteristics, enabling consistent, informed decision-making.

In our analysis, fiat-backed stablecoins such as USDC score relatively well on these dimensions. They maintain reserves in short-term Treasuries and cash, publish regular attestations, and offer one-for-one redemption to eligible customers. As a result, they tend to align closely with the economic characteristics of cash equivalents:

As an experiment, we have also built a rating that characterizes the consistency of stablecoins with the characteristics of cash equivalents, which unsurprisingly placed USDC as the most consistent stablecoin in this regard.

By contrast, other categories of stablecoins fall short.

• Some fiat-linked tokens have opaque or questionable reserves, weak transparency, or unresolved legal questions.

• Decentralized or crypto collateralized stablecoins, such as DAI, involve exposure to crypto asset volatility and usually do not offer a direct claim on fiat reserves.

• Algorithmic stablecoins rely on incentive mechanisms and related tokens instead of hard collateral and have historically been prone to collapse.

Algorithmic stablecoins use novel mechanisms (or other assets, such as commodities) to stabilize their value. These include purely algorithmic stablecoins (which have no hard collateral, relying on smart contract algorithms and often another token to absorb volatility) and crypto/commodity-backed tokens (e.g., stablecoins pegged to gold or baskets of assets). Such instruments are far too volatile or insufficiently liquid to be cash equivalents.

A notorious example was TerraUSD (UST), an algorithmic stablecoin that maintained its peg via arbitrage with a sister cryptocurrency and no fiat reserves. It collapsed in 2022, breaking its $1 peg and wiping out billions, illustrating the extreme risk of non-collateralized “stable” assets. Even if an algorithmic stablecoin temporarily maintains a peg, it lacks the guarantee of convertibility into fiat, as there is no pool of safe assets to back its value. These stablecoins should typically be treated as intangible assets and certainly would not qualify as cash equivalents under US GAAP.

Conclusion

In summary, only a narrow subset of stablecoins (those that function essentially like digital dollars) is appropriate to classify as cash equivalents. These stablecoins possess attributes that align with the definition of cash equivalents: they are highly liquid and carry an insignificant risk of value change, making them economically equivalent to holding cash.

On the other hand, many stablecoins should not be considered cash equivalents. Instruments like TrueUSD (TUSD2), despite their dollar peg, lack the full confidence in reserves and enforceable redemption. Decentralized or crypto-collateralized stablecoins like DAI involve inherent market risk and do not provide rights to fiat redemptions. And clearly, any algorithmic or non-fully backed stablecoin falls outside the bounds of a “safe” liquid investment.

As the FASB and regulators continue to refine crypto accounting rules, companies will need to evaluate each stablecoin on a case-by-case basis. The token’s design, collateral quality, legal structure, and the issuer’s governance practices will determine whether a specific stablecoin is reported as “cash equivalents” or falls into other asset categories.

FAQ

Are all stablecoins cash equivalents?

No. Classification as a cash equivalent is not automatic for any stablecoin. It depends on an entity’s accounting policy and whether a particular token meets the US GAAP definition of cash equivalents. Some fiat-backed stablecoins may qualify, but only if management explicitly elects that treatment and can support it on the basis of facts and circumstances.

Should USDC be cash equivalents?

It depends on management’s judgment and accounting policy. We believe there is a strong basis for an entity to elect to classify USDC as a cash equivalent, provided it confirms that USDC’s reserves, redemption mechanics, and liquidity remain consistent with the characteristics of cash equivalents and that the entity’s position size is appropriate relative to market depth.

What is the appropriate treatment of stablecoins under US GAAP?

There is no single standard treatment for all stablecoins. A reporting entity can adopt a policy to treat certain qualifying stablecoins as cash equivalents. Other stablecoins may be more appropriately classified as financial assets measured at fair value, as intangible assets, or under other categories, depending on their rights and risks. Classification should be revisited as market conditions, legal structures, and regulatory guidance evolve.

BACKGROUND

Being financially prepared for fundraising means a lot of work. You need clear, accurate records that reflect all interests in the entity and all amounts owed by the entity. Clean books drive better business decisions and signal reliability to outside stakeholders.

Raising capital through token financing can be attractive, but it often creates messy records. This lack of structure makes it harder for companies to fully understand their obligations and harder for investors to trust the information they are given. SAFTs and presale agreements are frequently tracked in spreadsheets, emails, or one-off documents that don’t connect.

CASE STUDY

A protocol team approaching the mainnet launch needed support in evaluating the accounting implications of converting previously issued Simple Agreements for Future Tokens (SAFTs) into tokens at the Token Genesis Event (TGE). The conversion terms involved multiple investor classes, different pricing tiers, vesting adjustments, and complex settlement mechanics.

We were engaged to determine the appropriate accounting treatment for the SAFT conversions and to prepare supporting documentation and reconciliation schedules in the anticipation of a future audit.

TechAccountingPro performed the following work to address the issue:

• Obtained all original and amended SAFTs and Token Purchase Agreements

• Analyzed each agreement to identify its economic substance

• Assessed whether the liability was extinguished through a conversion

• Evaluated the timing of recognition of unrealized and realized gains/(losses)

• Prepared a full reconciliation from SAFT commitments to blockchain transactions, showing the delivery of tokens (see our template below)

• Documented conclusions in a technical accounting memorandum.

Our analysis provided the client with clear, defensible accounting conclusions and a complete audit trail connecting token financing agreements and genesis block allocations, and helped identify all remaining unsettled liabilities that the company was able to resolve in the following month after the engagement had been concluded.

TEMPLATE

There are many token grant management solutions, but they are not designed to holistically track obligations to transfer tokens in advance of the token launch date.

To help with this, we’ve created a Token Presale Schedule template. It gives accounting teams a simple, structured way to record financing received through SAFTs. By organizing this data in one place, the template makes it easier to review obligations, support compliance, and build confidence with investors.

Our template, “Token Presale Reconciliation Template,” solves (or at least serves as a starting point for solving) this issue for FinOps teams of token issuers. The template could be used to organize information about token pre-sales to investors and understand the company’s obligations to deliver tokens for proceeds received. The template includes six tabs:

• Tab “BUYERS”: Identifying information for each investor who joined the fundraising round.

• Tab “PURCHASES”: Details of each token purchase, bonus, or return executed under each of the agreements.

• Tab “RECEIPTS”: Details of each payment received in connection with token purchases.

• Tab “PROCEEDS”: The total amount of all receipts net of refunded amount for each token purchase agreement.

• Tab “DISTRIBUTIONS”: Details of token transfer (both outgoing and incoming) for each token purchase agreement.

• Tab “SUMMARY”: The total amounts of proceeds received and receivable, as well as the value of tokens distributed and the remaining outstanding obligation to deliver tokens to investors who made a payment.

Download the template to start building cleaner, more reliable financing records.

CONTACTS

If you have any comments, improvement suggestions, or your team needs help with accounting for token grants to employees in compliance with US GAAP, reach out to us at info@techaccountingpro.com.

On proof-of-stake blockchains, the network's security is ensured by users who stake their scarce resources (crypto assets) on chosen validators. This is how it happens.

Validators deploy blockchain software binaries (compiled protocol code) on servers, whether owned or rented, that function as nodes on the blockchain network. This software enables validators to verify transaction accuracy and sequence and group validated transactions into blocks.

Validators are chosen from a pool to propose new transaction blocks. The selection follows protocol-specific rules that typically consider factors such as the number of staked tokens and a node's historical performance (e.g., past instances of downtime and double-signing). But to be added to the blockchain, each new block must achieve consensus among a set percentage or number of active validators. To achieve consensus, validators vote on proposed blocks using digital signatures generated from each node's private key. A validator's power to vote on proposed blocks directly corresponds with the number of tokens staked with the validator. Once voting is complete and a consensus has been reached, the newly forged block is added to the blockchain. The need for consensus means that any attacker on the PoS network must control a majority of the native tokens to succeed in a 51% attack. Thus, staking is designed to ensure the security of the blockchain network.

Validators earn rewards in two primary ways:

• First, by staking their own tokens, they receive staking rewards proportional to their investment. 

• Second, they share rewards with other users (delegators) who decide to stake their tokens with them by delegating them to validators. 

Thus, the reward system benefits both validators and delegators, providing two streams of income: direct staking rewards for validators and shared rewards for both parties.

In addition, validators often enter into agreements with blockchain foundations (or similar entities responsible for network governance), in which the foundations allocate returnable grants from the massive balance of native tokens to validators and give up delegator rewards for the benefit of validators. Foundations do this to incentivize validators who enter the ecosystem early. The rewards earned by validators on these assets are roughly 5-8%, compared to 0.01-0.05% for assets staked by delegators not affiliated with the Foundations (although these reward rates can vary widely across networks and over time due to changes in network policies, token economics, and market conditions).

Each blockchain is unique, and there are different variations of PoS. Some networks allow anyone to join as a validator as long as the new entrant has sufficient stake (e.g., 32 ETH on Ethereum), others have a limited number of validators (e.g, only 105 validators can be active on the Polygon network), and others have a combination of both (e.g, in the NEAR ecosystem).

Subscribe now

With this in mind, let’s dive into a few questions specific to staking revenue accounting in the financial statements of proof-of-stake validators in light of the requirements of ASC 606 “Revenue from contracts with customers”:

1. Know Your Customers. Who is the reporting entity’s customer?

2. Principal vs. Agent. Is the validator a principal or an agent in staking revenue arrangements?

3. Consideration Payable to Customers. Do delegator rewards fall under consideration payable to customer guidance?

Accounting Treatment of Validator Staking Income under US GAAP

Know Your Customers

The structure of staking arrangements is complex because it involves multiple parties acting as customers from the perspective of a validator. These customers are also directly involved in the provision of services by validators.

We can identify the following key parties of staking arrangements:

• Blockchain networks. Network protocols may be controlled by another business or nonprofit, or governed in a decentralized manner. As such, it is appropriate to identify the network as a separate entity. This entity may act as a customer of the validator. The network’s role is to pool transactions and allocate them to validators, who are responsible for building new blocks of the blockchain from those transactions in compliance with the established protocol rules.

• Users. The role of network users is to execute transactions on the blockchain. There are two subtypes of users:

  • End users who want to send crypto to another party or buy an NFT on a blockchain initiate transactions by submitting them to a blockchain client (e.g., a wallet). The client broadcasts submitted transactions to the network for validation. Validated transactions are included in a new block appended to the blockchain. Once a block is appended, the transaction is included in the blockchain. End users are the ultimate consumers of services provided by validators. However, end users should not be viewed as direct customers. They should be viewed as direct customers of the blockchain. Blockchain acts as an intermediary, setting protocols for network operation and for interactions between users and validators.

  • Delegators. Delegators are a subgroup of end users who engage validators to provision validation services to all network users. Delegators stake their limited resources to secure the network through the protocol’s built-in mechanism. Many (but not all) protocols transfer voting rights embedded in the staked assets from delegators to validators. To choose validators or to purchase crypto assets for staking, delegators must execute transactions on the blockchain network (either directly via an on-chain interaction with a staking smart contract or via the mechanism established by the custodian of the crypto assets). This means that delegators are customers of the protocol entity. However, staking arrangements do not oblige validators, nor do they oblige delegators, to pay any consideration in exchange for validation services rendered.

Staking arrangements include contracts between validators & delegators as well as validators & end users. Under ASC 606, both of these contracts should be combined and analyzed as a single arrangement because:

1. Delegators are always participants in the network.

2. Consideration payable under arrangements with delegators depends on the performance and rewards earned by validators in the arrangements with end users of the network.

As such, contracts with delegators are only contracts with customers to the extent that they are combined with validators’ arrangements to validate transactions on the network. Therefore, we can identify that:

• Delegators are de jure customers.

• Blockchain networks are de facto customers who engage validators to perform validation services.

• End users are indirect customers who consume the results of services delivered by means of the blockchain protocols.

Contract Combination Analysis

Institutional delegators often enter into separate formal legal agreements with engaged validators. These agreements might or might not modify the protocol's standard rules regarding validator commission levels, guarantees against potential slashing losses, or eligibility conditions for performance bonuses.

FASB ASC 606-10-25-9 will likely require a reporting validator entity to combine those contracts and account for them as a single contract because all three conditions for contract combination have been met:

1. Both contracts have a single commercial objective.

2. The second contract modifies the amount of consideration receivable under the standard blockchain protocol terms.

3. Services provided under both contracts constitute a single performance obligation to validate network transactions in accordance with the blockchain protocol rules.

Principal vs. Agent Analysis

ASC 606 requires us to assess whether we act as agents or principals for each good and service transferred to customers when other parties are involved. Staking services represent a single performance obligation. These services are performed for the blockchain networks AND delegators, as both customers are contracting with validators for the same service (transaction validation on the network), which represents a single combined performance obligation to ensure that the validator nodes are running with maximum up-time in a manner reasonably intended to arrange for the generation of digital asset rewards for delegators. Since there is only one service and validators are primarily responsible for such service, they are (clearly) the principal1.

In the US, public companies with significant staking revenues earned as validators are generally treated as principals in staking arrangements (with exceptions, such as SharpLink Games, Inc.; see the accounting policies section here). This is because, as validators, they control the only service being provided (transaction validation on blockchain networks). As such, we can find in these companies’ SEC filings disclosures stating that management records the gross amount of both validator and delegator rewards from staking as revenue. This is consistent with our conclusion above.

Analysis of the Guidance on Consideration Payable to Customers

The guidance on consideration payable to customers requires companies to assess any payments made to customers to determine whether they were made in exchange for a distinct product or service. Based on this understanding:

• Payments made without distinct services or goods received in exchange are treated as a reduction in revenue.

• Payments equal to or less than the fair value of distinct services or goods received are accounted as costs of goods or services purchased2;

• "An entity needs to determine whether consideration payable to a customer represents a reduction of the transaction price, a payment for a distinct good or service, or a combination of the two".

Depending on the blockchain, delegators act as either direct or indirect customers of validators. Because delegators are customers, rewards paid to delegators are subject to the guidance on consideration payable to customers. It would be easier to understand this issue if we accounted for the fact that the validator may never obtain control over delegator rewards, as these rewards (with rare exceptions) are automatically distributed to delegators by the protocol. However, both the delegator’s and the validator’s rewards are transferred in exchange for a single performance obligation (the validation of transactions on the network). The form/method of settlement does not affect whether the payment should be included or excluded from the transaction price (refer to Questions 25-26 of the Revenue Recognition Implementation Q&As published by FASB for further discussions).

The consideration payable to customers’ guidance applies to payments made to any customers in the distribution channel, including payments made in cash, equity instruments, or items that can be applied against amounts owed to the entity [606-10-32-25]. As the native cryptocurrency of the network can be applied against amounts owed to validators for services on this network, token payments to customers are subject to the guidance on consideration payable to customers. This, in particular, means that the transfer should be measured at the fair value of the tokens at the contract inception date rather than at the cost of the digital assets transferred to customers.

As such, our analysis may follow one of the two routes depending on whether a validator is believed to receive a distinct service(s) in exchange for delegator rewards:

• If delegation is not viewed as a distinct service, then the guidance would require us to reduce the transaction price by the amount of consideration payable to customers. This is because delegator rewards are paid in tokens, and delegators can apply these tokens against amounts owed to validators for transactions executed on respective blockchain networks. Hence, the noncash form of payment does not preclude us from accounting for these payments under the guidance for consideration payable to customers. As no distinct services are provided in exchange for consideration transferred to customers (delegators), these rewards should reduce the revenue reported in the validator's financial statements.

• If we were to conclude that delegation is a separate service (distinct from validation), it would imply that the primary responsibility for delegation services lies with delegators rather than validators. Hence, validators would act as agents of delegators, and related rewards would be presented by validators on a net basis.

Since the validator is a principal, rewards paid to delegators (customers) fall under the scope of the guidance on consideration payable to customers. Because no distinct service is being received in exchange for rewards transferred to customers, delegator rewards must be deducted from the transaction price. So, even though the validator is a principal, validators should present revenue net of delegator rewards.

Consensys recently brought up a different point of view that ultimately also supports the net presentation. See their communication with the SEC here.

To Be Continued…

Today, we discussed the accounting for staking revenue from the perspective of validators. We focused on the accounting treatment of staking income from the perspective of validators. For a comparison of how validators and delegators differ from an accounting perspective, see my companion article on delegator staking income

Introduction

The term “real-world assets” (RWA) refers to digital assets that represent an ownership right in another asset or an asset pool.

Examples of RWA:

• Stablecoins

• Tokenized real estate

• Tokenized corporate stock

• Tokenized treasury notes

Background

Real-world assets fall outside of the definition of the crypto assets in FASB ASC 350-60-15-1 because RWA tokens by its definition provide holders with a claim on a real-world asset these tokens represent. So how should companies holding RWA tokens account for such tokens? To answer, we analyzed common business models of issuer entities, redemption rights provided by tokens, and key risks associated with RWA tokens. The brief summary of this analysis is provided below.

Subscribe now

Business model

The business model consists of 4 steps (Steps 1and 2 might take place in any order):

• Step 1. Management sells fractionalized ownership/redemption rights.

• Step 2. Management acquires the underlying assets.

• Step 3. Management generates income via:

  • Earning interest on cash deposited in a bank.

  • Lending financial assets to short sellers.

  • Staking assets.

  • Renting out a property.

• Step 4. Management retains 100% of the income from operating the underlying asset.

Redemption rights

Typically, an RWA does not represent an ownership interest in the actual asset. A special-purpose legal entity owns the underlying asset and issues tokens. This entity grants holders of RWA tokens the right to redeem their tokens for cash or the entity’s property.

Redemption rights might be unlimited or limited to a special group of intermediaries who guarantee the redemption-like rights to retail token holders.

Redemption rights for underlying non-financial assets might be exercisable in cash (assuming the entity holds cash generated from operating assets) or in kind. In-kind redemptions often require the holder to meet a threshold of ownership that may reach 100% for indivisibles assets.

Business risks

For RWA token holders, the two main risks associated with this business model are:

• Loss or damage of the underlying asset in the course of operation.

• The occurrence of an event triggers the creation of a material legal liability with a higher priority.

Accounting by the token holder

The acquirer of an RWA token should account for it as an acquisition of a debt or debt-like instrument.

Tokens redeemable for fiat, whether conditionally or unconditionally, should be treated as a financial asset. This is consistent with the definition of financial assets provided in the FASB master glossary: “A financial asset is cash, evidence of an ownership interest in an entity, or a contract that allows one entity to receive cash or another financial instrument from another entity.”

Tokens that can only be redeemed for property should be treated as non-financial receivables. Further, when a non-financial asset can be readily converted to cash, reporting entities might be able to choose an accounting policy to either:

• Remeasure the RWA token instrument at its fair value (by analogy); or

• Determine whether the instrument contains an embedded derivative that requires bifurcation and separate recognition.

Conclusion

The nature of the RWA token drives its classification and subsequent measurement. However, the process of determining the nature of RWA tokens and associated rights and obligations is often a complex judgmental error-prone process. Reporting entities need to carefully evaluate specific contractual terms of each individual arrangement and account for all relevant facts and circumstances.

Introduction

Earlier this month, Paxos accidentally minted $300 trillion of PYUSD, PayPal’s dollar-backed stablecoin. The mistake was quickly detected, corrected, and disclosed. Paxos issued an announcement confirming the mint and immediate burn:

Almost immediately after the tweet, PYUSD’s price fell slightly below $1.00, reaching $0.99927 at 5:00:03 PM EST, according to CoinGecko, showing almost no sensitivity to the event.

Five days later, on October 20, 2025, KPMG issued its Independent Accountant’s Examination Report, concluding that as of 6:00:00 PM on October 15, both total PYUSD tokens outstanding and redemption assets available were “fairly stated, in all material respects.”:

While an affirmative report from a Big Four auditor is a notable milestone, it’s important to note that the examination did not assess the design or effectiveness of Paxos’ internal controls.

Many have argued that a comparable mistake in traditional finance (TradFi) would likely never be visible to outsiders and would take longer to fix if it were.

Perspectives

This event highlights operational and control challenges facing all stablecoin issuers, and, more broadly, the evolving landscape in issues related to blockchain transparency, regulatory oversight, and financial accountability.
We spoke with two industry leaders who are shaping how the next generation of issuers approach compliance and risk management.

Jonathan Rose, BlockTrust IRA

Jonathan Rose, CEO of BlockTrust IRA, noted that since the passage of the GENIUS Act, he’s observed “…the complete reimagining of compliance as a core business strategy, not a peripheral requirement”.

According to Mr. Rose:

“We’re witnessing the emergence of what I call ‘Compliance-First’ stablecoin models…” with “Innovative approaches include blockchain-based proof of reserves, where every transaction is instantaneously verified and recorded, creating an unprecedented level of financial transparency.”

He pointed to innovations such as blockchain-based proof of reserves, where each transaction is verified and recorded in real time, creating a new standard of financial visibility.

Rose also described BlockTrust’s internal model:

“…Similar to the infrastructure we’ve built at BlockTrust, my recommended approach would include advanced multi-signature wallet architectures that require multiple independent verifications for any significant transaction. We’ve implemented machine learning-powered anomaly detection systems that can identify potential errors or malicious activities in milliseconds…”

Finally, Rose offered a longer-term perspective:

“…Our market projections indicate growth to $3 trillion by 2030, but this expansion is now intrinsically linked to our ability to demonstrate absolute reliability and transparency… The most exciting chapters of digital finance are yet to be written, and we need to be authoring them with integrity, innovation, and an unwavering commitment to the end users.”

Connor Dempsey, Crossmint

Our following conversation was with Connor Dempsey, Head of Marketing at Crossmint, a startup developing infrastructure for institutions and high-growth fintechs, including stablecoin issuers such as Circle.

Dempsey emphasized that one-size-fits-all compliance no longer works:

“Each company needs tailored risk management standards. Regulators are looking at each issuer’s specific business model and risk profile. A company issuing $100 million in stablecoins for cross-border remittances faces different operational requirements than one managing $10 billion for institutional treasury operations. Companies can right-size their compliance infrastructure to match their actual risk exposure….”

He highlighted hybrid custody setups as a major trend:

“….These combine custodial and non-custodial wallets to serve global user bases: custodial in regions where companies are licensed, non-custodial where they’re not. This strategy enables enterprises to meet differing regulatory requirements across jurisdictions while preserving flexibility for both the company and its customers. The hybrid custody model is also a critical safeguard for larger enterprises that want to adopt stablecoins. Smart wallets with programmable controls, such as spending limits, velocity rules, and key rotation capabilities, provide both security and operational flexibility…”

Dempsey also shared a clear framework of core safeguards issuers should implement:

1. “Segregated hot and cold wallet operations

2. Multi-signature requirements for any significant transactions or manual interventions in automated systems

3. Real-time monitoring with automatic circuit breakers.

4. Real-time sanctions screening and compliance monitoring embedded directly into transaction flows.”

Reflecting on the Paxos incident, he concluded:

“…PYUSD maintained its peg, trading continued normally, and confidence wasn’t shaken. That’s because the transparency and rapid remediation actually demonstrated the system working as designed. This is why blockchain-based systems are more trustworthy than traditional finance, not less. A bank could have hidden this error from public view. When everything is on-chain, it’s visible and auditable. Modern stablecoin infrastructure needs to be built with transparency as a feature, not a bug. If anything, it’s pushing everyone to implement enterprise-grade controls faster. The companies that invest in robust operational infrastructure now will be the ones that scale successfully under the new regulatory framework.”

Conclusion

Based on our conversations, this is a maturing industry rapidly aligning around operational safeguards and controls, which can be grouped as follows:

1. Preventive Controls:

   1. Multi-signature smart wallets with programmable controls (key rotation, spending limits, velocity rules)

   2. Machine-learning systems for anomaly detection and compliance screening

2. Detective Controls:

   1. Proof of Reserve Attestations

   2. Real-time monitoring tools.

The Paxos event, while harmless in financial impact, is invaluable as a case study. It highlights that blockchain transparency is only as effective as the operational discipline that underpins it. Stablecoin issuers, auditors, and regulators now share a common mandate: trust through verifiable control.

We’ll continue exploring this theme in future posts, including deeper assessments of internal controls and audit readiness for stablecoin issuers.

The sandwich attack involves two transactions sent to the blockchain to be executed immediately before and after your transaction, to manipulate exchange rates and recapture a portion of the swap value. After slippage, MEV, gas, and exchange fees, the value of tokens received is often less than the value of tokens surrendered. How common are sandwich attacks, and how big of an impact might they have on an individual swap transaction?

Share

In the last 24h on Solana alone, 2,344 victims were sandwiched. It is easy to learn more details by visiting the website https://sandwiched.me.

One of the most recent transactions I see at the time of writing this post extracted about 30% of the swap value (the victim sent 0.584 SOL worth of tokens and received only 0.404 SOL worth of tokens as a result of one attack).

For businesses that are not sophisticated in managing security threats and are unaware of how to protect themselves from a sandwich attack, the impact might be significant.

It is interesting how cybersecurity issues can directly affect fair value measurement.

Audit procedures to support the completeness, existence, and accuracy of crypto assets account balances and transactions often use blockchain information as audit evidence. Auditors use various methods to acquire relevant data from public blockchains, including obtaining it from third-party data vendors. The “Accounting for and auditing of digital assets” Guide by AICPA briefly mentions some considerations relevant for auditors engaging a third party to obtain blockchain information. But today, we are going to try to dig a little bit deeper and understand the blockchain information acquisition process in more detail.

We will focus only on service organizations that supply blockchain data but do not authorize or initiate transactions. These providers often bridge blockchain data and tidy, tabular reports suitable for accounting systems, a step frequently overlooked in the literature.

As a valid alternative to running their own node infrastructure, auditors can use a third-party vendor. Firms might engage a third-party vendor directly or obtain it from the audit client. Respectively, auditors using the blockchain information received from third-party data vendors will follow a testing approach consistent with the selected approach to data acquisition:

- Information received directly from the external source when using a substantive testing approach.

- Information received from the entity when testing controls.

The sections below outline relevant considerations.

Blockchain Data Observability

Most third-party blockchain APIs alone rarely provide enough information to reconcile an account balance due to non-transaction state changes and other factors. Auditors must use alternative methods.

Now, let’s briefly discuss raw blockchain data structures and outline the steps needed to access raw blockchain data.

Not all data recorded on blockchain is relevant to auditors, and not all pertinent data for auditors is directly captured on the blockchain. There are two generalized data elements relevant during the audit of financial statements of companies that are involved in digital assets:

- State, which is a value assigned to a record at a specific block height (i.e., the number of a block in the blockchain). On Ethereum, includes:

“In Ethereum, state includes:

• Account balances and nonces

• Contract code

• Contract storage

• Consensus-related data (some recent block hashes, uncles, proof-of-stake consensus data such as validator pubkeys and activity records on the beacon chain, etc)”

[“A Theory of Ethereum State Size Management” by V. Buterin on 02/12/2021]

- State Transition, which is a change in a value assigned to a record between the block height specified and the immediately preceding block height.

Blockchain does not always capture every state and state transition because doing so would be computationally expensive. Some blockchains record both; others track only one, or neither, but allow recomputation. Each blockchain, and each smart contract, has its own way of recording state and transitions.

The process of data acquisition includes the following steps:

1. Downloading the blockchain node software

2. Installing the node software and spinning up the node. This includes connecting and syncing the node with the network. During a sync, depending on the storage mechanism used by the node software, there are risks of incomplete data download, partial loss, or corruption of downloaded data, and unaccessibility or unreadability of downloaded raw blockchain information. This might happen due to:

   1. Storing individual blocks in separate files (Bitcoin and Bitcoin Cash).

   2. Selecting the wrong sync mode results in a loss of information about transactions that occurred prior to the period covered by a light node scope.

Subscribe now

3. Direct Query. Once the node is synced, it might be possible to query the node directly using its native RPC interface. When querying the node RPC interface, we do not access or observe raw blockchain data. We rely on the node software code to be designed appropriately and to return the data it promises based on the documentation (if such documentation exists, which is not always the case). However:

   1. Bugs in the node client software that eliminate the ability to use standard commands to extract needed data via the node RPC interface, such as querying the blockchain state at a specific block height.

4. Data Indexing. Raw blockchain blocks are encoded and unreadable. Auditors needing to manipulate or filter data must preprocess it with indexer software. Indexers organize the data, but this requires understanding both on-chain data structures and the result of executing blockchain code on that data. Risks include:

   1. Inappropriate indexing code logic results in incomplete or inaccurate data being returned. This is not a trivial task at all. Here is a post about a prominent security research firm trying to determine the number of all smart contracts deployed on Ethereum using different approaches and receiving drastically different results.

   2. Missing or incorrect reference files, including Genesis files containing the initial allocation of tokens to wallets on Day 0 and Application Binary Interfaces (ABI) of smart contracts. This data is not stored on the chain, and it might not be possible to index a smart contract without knowing its ABI or to determine the account balance without a genesis file.

5. Indexed Data Storage. Indexed data is typically saved in a modern fast database (“serving database”), which is convenient for querying using SQL to extract human-readable data with the required fields and values. Risks arising at this point include:

   1. Data loss or corruption occurs during the initial operation performed to record indexed data in the serving database.

   2. Data loss or corruption can occur while storing data in the database. For example, physical disk damage or malfunction can cause data loss.

   3. Incorrect logic of SQL queries from the indexed database results in incomplete or inaccurate data being returned.

6. Transmission. Finally, auditors receive data via email or API in the form of a PDF report, Excel or CSV file, or other format. The main risk is inappropriate modification of data during transmission for various reasons.

Understanding these risks and the responses in place to address them is key to the successful use of blockchain information as audit evidence.

Share

1) Information received directly from an External Source

In the context of an individual audit engagement, a third-party blockchain data vendor used by the audit firm is an external source of information. Hence, auditors need to consider the requirements for using information received from external sources as audit evidence.

PCAOB Staff Guidance [1] provides some helpful reminders about how auditors should approach audit evidence obtained from external sources. When using information about historical balances received directly from a third party as audit evidence, auditors need to consider the relevance and reliability of the information.

Relevance measures how well audit information aligns with the audit procedure’s purpose. When testing digital asset balances, the quantity of tokens in the wallet at the end of the period is directly relevant.

Reliability of audit evidence depends on sufficiency (quantity) and appropriateness (quality). Information about asset quantities at year-end may or may not be reliable. How do we assess reliability?

Many practitioners believe a SOC 1 or SOC 2 from the blockchain data vendor is enough to assess the reliability of the information received.

SOC I Type 2, if it tests controls over report completeness and accuracy, can help. When auditors use vendor reports directly, a SOC report alone generally is not enough to ensure client-specific information is complete and accurate because:

a) Service auditor reporting on the blockchain data vendor performs audit procedures using sampling at the level of the vendor. The sample size might not be sufficient to provide the level of assurance consistent with the tolerable misstatement threshold used for the purposes of the audit of the reporting entity.

b) If the reporting entity relied on the information received from the blockchain data vendor with reference to the SOC I Type 2 report, management would have to do a considerable amount of additional work to avoid the deficiency in its internal controls (refer to the next section for further details). It would not be appropriate to state that audit firms can rely on the same information without needing to perform additional work to validate it.

Key considerations for reliable external audit evidence include:

1. Independence, competence, expertise, and capabilities, including the infrastructure reliability of the vendor and the use of third-party vendors.

2. Limitations and disclaimers that affect the use of the vendor’s data.

3. Cybersecurity, known vulnerabilities (unresolved), and responses implemented by the vendor.

4. The risks associated with a specific blockchain network.

5. Responses to data integrity risks occurring throughout the full lifecycle of data (see the previous section).

2) Information Received from the Entity (Client Using a Service Organization)

Reporting entities (e.g., web3 startups) may rely on a blockchain data provider if both of the following are true:

a) During the relevant period, the vendor maintained effective controls over relevant processes and specific data reports used. This assessment is based on the SOC 1 Type 2 report received from the service organization and bridge letters showing results of subsequent testing during the interim periods between the service organization’s year-end and the period-end date of the user’s financial statements being audited.
b) Management designed and implemented:

• Complementary user-entity controls identified in the vendor’s SOC 1 Type 2.

• Compensating controls to mitigate any deficiencies identified in that report; and

• Entity-specific controls over risks at the reporting entity are not sufficiently covered by the vendor’s SOC 1 Type 2.

Accordingly, auditors may rely on blockchain data that:

1. is received from the client,

2. which the client obtained from a service organization,

3. with a SOC 1 Type 2 report,

4. covering processes, controls, and reports relevant to the entity, and

5. is supported by effective controls implemented at the level, allowing us to ensure that relevant information to the reporting entity is complete and accurate for financial statement purposes.

When these conditions are met, auditors might be able to rely on blockchain data received from an external vendor. To rely, the auditors’ testing approach should be designed assuming the auditors’ reliance on the effective design and operation of relevant internal controls of the audit client. To rely on controls, auditors should test those controls, including those over the accuracy and completeness of blockchain information received from the service organization (blockchain data vendor).

If these conditions are not met, reliance on data received from an external vendor API is generally not appropriate.

Conclusion

Unfortunately, blockchain data cannot be directly observed by auditors. The data transformation process is complicated and prone to errors. Regardless of the data source and testing approach, there are numerous risks related to the completeness and accuracy of the human-readable representation of blockchain information used by auditors. To address these risks and obtain sufficient audit evidence, auditors will likely require further audit procedures.

[1] Spotlight Reports “Data and Reports” and “Evaluating Relevance and Reliability of Audit Evidence Obtained from External Sources”

Raising the money and opening funds takes a lot of time. But sometimes a great investment opportunity knocks on the fund’s door before all formalities are settled. What happens next?

If this investment opportunity matches the objectives and strategy of the fund that is not yet closed, the general partner/advisor1 or the affiliated legal entity steps in and acts as the warehousing provider for the fund. This warehousing provider executes the investment purchase agreement before the fund’s first close date.

Once the necessary funds were committed:

• Advisor sends capital call notices to investors.

• Investors transfer cash to the fund’s bank account.

• The fund now deploys money to repossess the investment.

The warehousing provider assigns and the fund assumes the investment in exchange for consideration, which is separately negotiated. Typically, this price reflects the third-party valuation or the cost of the original purchase and funding.

Shahrukh Khan here has published a great Substack post where he explains what the “warehoused investment” is and when it is being used from a legal perspective.

Treatment

The intent of the transaction is to make the purchase on behalf of the fund. In practice, the reporting entity (which is acting as a warehousing facility) might perceive this transaction as if it were acting purely as an agent. The reporting entity transfers to the fund “the rights and duties of a party under an existing contract” 2 rather than “the ownership of assets and property “3.

As a result of this perception, the reporting entity might not be willing to recognize gains or losses on the transaction in the financial statements of the warehouse facility’s entity. However?

• First, it is not uncommon to warehouse investments on behalf of funds that have not yet been formed as legal entities. It is difficult to argue that the reporting entity acted as an agent for the fund that did not yet exist when the investment was acquired.

• Further, transfer conditions may limit the ability to transfer the investment to the entity on whose behalf the purchase was made.

Let’s consider the accounting guidance provided by FASB from the perspective of the reporting entity acting as a warehousing facility.

Scenario

We use the following assumptions:

• The underlying investment is a token that is not traded on an exchange.

• The fund is not legally formed as of the date of the original purchase of the underlying investment.

• The warehousing facility does not issue debt to a third party to finance the purchase of underlying assets.

• The original purchase agreement is between the warehousing provider and the investee and does not identify the legal entity on behalf of which the facility is acting. Further, no formal agreement was executed between the fund and the warehousing provider.

• The terms of the wareshoused investment are not fully disclosed to prospective capital allocators before they commit to investing in the fund.

• The applicable law does not grant the facility enforceable rights of recourse towards the fund.

Question 1: Should the reporting entity recognize a loan issued to the fund for which the investment is being warehoused?

Answer 1: Depends on the specific terms of the agreements, but not in the scenario described. This is because NO separate enforceable agreement is entered into between the reporting entity that warehouses the investments and the fund on behalf of which the investment is being acquired.

The fund does not issue a debt security instrument. The fund may elect to purchase some but not all of the assets held by the warehouse facility. No legally enforceable creditor’s rights are created until the assets are assigned to the fund at a later date.

Question 2: Should the reporting entity recognize the underlying warehoused investment as an investment made on its own?

Answer 2: Yes, if the reporting entity (the warehousing provider) has the power to direct the use of the investment prior to the assignment to the intended entity.

Question 3: Should the reporting entity recognize gain/(loss) on the disposition of the warehoused investment?

Answer 3: The accounting for derecognition of the investment under the described scenario will be within the scope of the guidance on derecognition of respective accounting categories of assets. The accounting for the disposition of the investment to a non-customer will likely be in scope of FASB ASC 610, Other Income. Hence, the reporting entity will record gain/(loss) at the time of the transfer of control.

In this post, we examine how rebasing works, the complexities it creates in accounting, and how to query historical balances using archival blockchain data.

What are Rebasing Tokens?

“Rebasing” liquid staking tokens automatically adjusts their balance in users’ wallets to reflect staking rewards. Examples of these tokens include AAVE’s sUSDC, Ankr’s aDOTb, Ampleforth’s AMPL, Lido’s stETH, Origin Protocol’s OETH, Olympus DAO’s sOHM, and Klima DAO’s sKLIMA.

Subscribe now

Shares vs. Balances

When depositing assets into a liquid staking protocol that employs rebasing tokens, users receive a fixed number of “shares”. A user’s wallet displays the token balance returned by a smart contract query. But the smart contract query does not return the number of shares. Rather, it returns the balance calculated as:

[Total ETH in the Pool] * [User Shares] / [Total Shares],

…where:

[Total ETH in the Pool] = [Staked by the Pool ETH] + [Accrued by the Pool ETH Rewards].

As a result, the user’s balance of tokens in the wallets increases daily without incoming transactions.

Accounting Implications

For accounting purposes, the choice between using shares or token natural units depends on the token. Shares are typically static unless a transaction occurs, while token natural units may change even without transactions. The shares variable is typically private, but some contracts allow external access to it for accounting purposes. For instance, Lido’s stETH (deployed version with an address 0x17144556fd3424EDC8Fc8A4C940B2D04936d17eb) exposes both sharesOf() and balanceOf(), whereas sKLIMA exposes only balanceOf().

Historical Balance Queries

This can be illustrated using the sKLIMA token on Polygon Network (Contract 0xb0c22d8d350c67420f06f48936654f567c73e8c8).

Displayed using the following implemented in the contract read-only method balanceOf (0x70a08231). You can view it in the user interface here.

The main issue we see in practice is that querying balanceOf() returns the current state of the account, and the user cannot query the historical balance by default. But accountants need balances for a specific time in the past (month-end, or immediately prior to a transaction). Is there a way to obtain this data? Yes, we can do it if we get a little bit more technical. All we need is a block height, access to an archive node, and a preferred code execution environment.

Block height is the sequential number assigned to the most recently mined block included in the blockchain at a specific date and time. For example, as of the date and time when this post was written, Polygon included approximately 77 million blocks, each with a timestamp.

Knowing the block height at a specific point in time in the past, we can query an archival node with a specified block height to return the same result that would be returned by the method if we were to send this request at the desired point in time in the past.

If the node you’re using is not archival, calls for old blocks can fail or return incorrect/unavailable data. Hence, we need a blockchain node provider that provides access to a full archival node (which might not exist for less commonly known blockchains).

Chainstack is the only provider offering access to archive node on Polygon network that I was able to find. Alternatively, you can set up your own node to obtain data directly, allowing you to avoid relying on SOC reports from external providers and ensure the integration of node controls with your entity’s control environment.

So, how do we determine the block height that should be used in a query of the historical account balance?

There are two ways:

1. The block height for the datetime associated with a specific on-chain transaction can be found in the details of the blockchain transaction.

2. Locating the block height for the end of a specific reporting period is more challenging. But for blockchains available in Google Big Query, we can get the list of block heights for each month-end using this simple query:

  FORMAT_TIMESTAMP(”%Y-%m”, timestamp) AS month,
  MAX(number) AS latest_block_number,
  MAX(timestamp) AS latest_block_timestamp
FROM bigquery-public-data.crypto_polygon.blocks
GROUP BY month
ORDER BY month;

Great. Next question: how do we query the archive node to receive the account balance at a specified block height?

We will use the Google Collab environment to run the code and populate the two code cells as follows:

Cell 1:

!pip install web3

Cell 2:

from web3 import Web3
contractAddress = “0xb0C22d8D350C67420f06F48936654f567C73E8C8”
holder = “0x89C825392C739c355Fee242cfAA85C7fcD90f419”
block_number = 76621446
abi = [
    {
        “inputs”: [{”internalType”: “address”, “name”: “who”, “type”: “address”}],
        “name”: “balanceOf”,
        “outputs”: [{”internalType”: “uint256”, “name”: “”, “type”: “uint256”}],
        “stateMutability”: “view”,
        “type”: “function”,
    }
]

# Use your Polygon RPC provider URL
POLYGON_RPC_URL = “https://polygon-mainnet.core.chainstack.com/xxxxxxxxx”
w3 = Web3(Web3.HTTPProvider(POLYGON_RPC_URL))
# Sanity check
print(”Connected:”, w3.is_connected())
contract = w3.eth.contract(
    address=Web3.to_checksum_address(contractAddress),
    abi=abi
)
bal = contract.functions.balanceOf(holder).call(block_identifier=block_number)
print(”Balance at block”, block_number, “:”, bal)

Once we run Cell 1 and Cell 2, we receive a message:

Let’s try to run the same code with the older block (ID 56640046). The code returned the following response, indicating a successful request:

Connected: True
Balance at block 56640046: 29464021721

To validate the accuracy of the returned data, we can verify the smart contract state using proof. Leo Zhang discussed how to do this in an excellent article Verify Ethereum Smart Contract State with Proof.

I want to extend my sincere thanks to Isaac, Casper, and Jalal for their valuable contributions. Their expertise and guidance greatly enriched this piece, and I’m grateful for their support throughout the process.

Introduction

Market-making activities are subject to numerous legal controversies and should be carefully assessed to ensure that the exact service provided to the reporting entity complies with the laws of the relevant jurisdictions. A few legal cases against vendors providing market-making services in the US are listed below1:

• CLS Global FZC LLC

• Gotbit Consulting LLC

• ZM Quant Investment Ltd

Before diving into the detailed models, it is helpful to first clarify the core function of market makers (the “MMs”) in Web3. This context will provide a foundation for understanding the models discussed in the following section.

Market makers offer sophisticated services designed to ensure sufficient liquidity on both the buy and sell sides of markets where issuers’ tokens are actively traded. Consequently, market-making services reduce the bid-ask spread, facilitating easier and more efficient trading for investors with minimal price slippage.

To further understand these functions, it is important to examine the main market-making models. The next section draws on a post from Flowdesk, which identified two primary models (retainer model and loan/call option model). Additionally, we note an extra arrangement often used, which we refer to as the liquidation model.

1. Market Making Models

1.1. Retainer Model

Under this model, the company pays a monthly retainer and provides liquidity to a market maker using a mix of its own tokens and cash or stablecoins, which are returned at the contract end. Market makers often deduct retainer fees directly from loaned assets. As a result, calculating outstanding balances requires strict reconciliation procedures to ensure that each month's retainer is accurately recognized as an expense, even if it is offset against loaned assets instead of paid in cash. If offset, record a debit to the expense (or prepaid expense) account and a credit to the token loan receivable.

1.2. Loan/Call Model

In this model, the issuer loans tokens to the market maker, who provides liquidity and executes trades. Simultaneously, the issuer grants the market maker a call option to purchase tokens at a predetermined price. The market maker may settle the loan by:

1. Returning the original number of tokens or

2. Exercising an option (if the market price of the token exceeds the agreed-upon price) and returning to the issuer cash or stablecoins in the amount equal to the fair value of the tokens as of the inception date.

Under this model, the market maker is compensated via the call option and gamma trading of the option [Flowdesk].

The market maker uses the issuer's tokens to support buy orders, deploying them on the buy side of the market. The market maker provides cash from their own assets for these trades.

1.3. Liquidation Model (separate arrangements)

In addition to the above, market makers assist token issuers with the liquidation of tokens on the open market in a manner that minimizes the impact of such liquidations on the market price. This is an additional service that requires a separate accounting. In such an arrangement, a market maker acts as an agent of the token issuer. This is because TI directs how MM is supposed to use (dispose of) the asset, leaving MM to determine the exact timing and structure of the dispositions.

2. Accounting Process

This section reviews the accounting considerations relevant to typical activities that token issuers (TIs) undertake when engaging market makers (MMs):

1. Liquidity Provisioning

   TIs transfer liquidity to MMs.

2. Operations

   MMs use this liquidity to execute trading operations on exchanges. TIs monitor the receivable balance due from MMs. TIs also account for activities that affect this balance with MMs.

3. Liquidity Deprovisioning

   MMs return the liquidity to TIs at the end of the contract term.

2.1. Liquidity Provisioning

“If an entity transfers a nonfinancial asset in accordance with paragraph 350-10-40-1, and the contract does not meet all of the criteria in paragraph 606-10-25-1, the entity shall not derecognize the nonfinancial asset and shall follow the guidance in paragraphs 606-10-25-6 through 25-8 to determine if and when the contract subsequently meets all of the criteria in paragraph 606-10-25-1. Until all of the criteria in paragraph 606-10-25-1 are met, the entity shall continue to do all of the following:

1.Report the nonfinancial asset in its financial statements…

…3.Apply the impairment guidance in Section 350-30-35.”

[FASB ASC 350-10-40-3]

After transferring tokens to market makers, subject to contract specifics:

• TI may retain the ability to direct or supervise MM activities2.

• TI may be able to direct MM to liquidate a portion of the tokens to finance operations and remit the proceeds from the liquidation to TI.

• TI may be able to access information about token balances held by MM and market indicators from exchanges where MM operates.

Market makers must generally have the authority to direct the use of tokens in order to operate effectively and meet their obligation to act in the best interest of the token issuer. The extent of this authority depends on the specific contractual terms. Generally:

• Under the retainer and loan/call option model, the TI (issuer) transfers control of the tokens to the MM (market maker). Derecognition means that the TI removes the tokens from its balance sheet and recognizes a token loan receivable at its fair value at the time of transfer. See the respective section below for details of accounting for token loan receivables.

• Under the liquidation model, TI retains control, and the tokens remain on its balance sheet. As a result, market makers’ trading operations will result in the recognition of exchange transactions with the company’s assets.

2.2. Operations

2.2.1. Token Loan Receivable

Under the liquidation model, both tokens transferred and proceeds from sales of such tokens are treated as TI’s assets held in the custody of an MM. When tokens are sold on the exchange, gain/(loss) is recognized by TI using the cost basis of tokens and the fair value of sale proceeds.

The remittance of proceeds from the MM back to the TI is essentially a transfer of cash between two financial institutions. For example, assume the MM received stablecoins in exchange for tokens sold on behalf of the TI. The TI’s chart of accounts should allow separate tracking of stablecoins held with the MM and those held in the TI’s wallet. A transfer of stablecoins from the MM’s account to the TI’s wallet does not result in recognition, derecognition, gains, or losses.

Under the loan/call option model, the token issuer (TI) does not account for sales and purchases of tokens executed by the market maker (MM). Instead, the TI continues to account for the token loan receivables (amounts the MM owes for the borrowed tokens) and the related call option derivative (a financial instrument that gives the MM the right to buy tokens at a set price) until the loan has been repaid.

Under the retainer fee model, the TI does not make accounting entries for token sales and purchases made by the MM. This means TI does not directly record the MM's trading activities related to its tokens.

US GAAP does not explicitly address accounting for the lending of tokens. We summarized below the latest views expressed on this topic within the AICPA’s Practice Aid “Accounting for and Auditing of Digital Assets“ and Deloitte’s Guide “Digital Assets“:

• Loaned tokens are derecognized upon transfer, with the corresponding token loan receivable initially measured at the fair value of the tokens at the time of the transfer.

• Subsequently, the token loan receivable is remeasured based on changes in the token's fair value.

• The current expected credit losses allowance is determined by analogy with the requirements of ASC 326.

• Token interest income may be presented as “Interest income” along with fiat interest income.

Under this view, token loans are accounted for similarly to loans denominated in foreign currency, where the issuer’s own tokens serve as such foreign currency. It is important to note that, consistent with ASC 815-15-15-19, it would not be appropriate to analogize the embedded derivative accounting guidance that addresses certain foreign currency derivatives.

2.2.2. Call Option

Typically, the token loan (market-making) terms incorporate a call option as part of a single agreement. As such, a single legal document governs the two instruments (i.e., a token loan receivable and a call option).

However, the call option is NOT a freestanding instrument because it is neither:

1. Separately entered into, nor

2. Legally detachable and separately exercisable.

The token loan receivable is not a derivative, as it requires an upfront investment equal to the notional amount. As such, the call option attached to a token loan is accounted for separately from the token loan receivable using the guidance for embedded derivatives.

Below, we assume that hedge accounting does not apply.

2.2.2.1. Identification and bifurcation

The embedded derivative related to the call option should be evaluated under the requirements of FASB ASC 815-15-25-1 to determine whether an embedded derivative requires bifurcation and separate accounting. The following conditions should be met for the embedded derivative to require bifurcation:

A) CLEARLY AND CLOSELY RELATED CRITERION.

Requirement:

The economic characteristics and risks of a call option should not be closely related to the token loan contract.

Analysis:

The host contract of this hybrid instrument is a debt instrument because it has a stated maturity and does not grant voting rights or entitle shareholders to receive distributions. The embedded derivative is a token-based derivative that has as its underlying the fair value of the issuer’s token.

The call option gives the MM the right to settle in stablecoins using the token value based on a contractually fixed price. That option subjects the arrangement to an additional market price risk that is not inherent to the debt instrument. As such, the call option is not clearly and closely related to the host contract and must be separated from the host contract and accounted for as a derivative.

B) SEPARATE INSTRUMENT CRITERION.

Requirement:

If entered separately under the same terms, the call option should fall within the scope of ASC 815.

Analysis:

We need to determine whether the embedded derivative issued as a separate instrument would have characteristics listed in FASB ASC 815-10-15-83(a) – “Underlying, notional amount, payment provision” and 815-10-15-83 (c) – “Net settlement”, and would not fall under any of the ASC 815 scope exceptions.

The characteristic (a) “Underlying” is present as the contract has as its underlying the fair value of the issuer’s token receivable.

The characteristic (a) “Notional amount or payment provision or both” is present because the token loan contract has the notional amount (which is the number of tokens borrowed) and also a payment provision that specifies a fixed or determinable settlement to be made if the fair value of tokens reaches the strike price (i.e. if the underlying behaves in a specified manner).

The characteristic (c) “Net settlement” is present, as the contract provides for the delivery of readily convertible to cash assets, which puts the recipient in a position not substantially different from that of net settlement.

We believe that none of the scope exceptions apply, as the loan is denominated in the issuer’s own tokens, which cannot be analogized to foreign currency or equity instruments.

C) FAIR VALUE OPTION CRITERION.

Requirement:

The token loan receivables should not be measured at the fair value.

Analysis:

Under ASC 825-10-15-4, reporting entities may elect to account for token loan receivables under the fair value option (FVO). This election is being made on an instrument-by-instrument basis and is irrevocable. If the FVO is elected, the embedded derivative is not bifurcated and separately recognized. Furthermore, if the FVO is elected, the entity would also not be required to determine the allowance for currently expected credit losses on token loan receivables by analogy with ASC 326.

It should be emphasized that the fair value option refers to the election to remeasure the fair value of the receivable, not the fair value of the underlying tokens. The fact that the token loan is remeasured based on the fair value of tokens does not indicate that the loan receivable is measured at its fair value.

Finally, option calls with barriers are not as intuitive or easy to value for anyone who is not regularly practicing the valuation of similar assets. Excel might be suitable for calculating the fair value of relatively straightforward call options, but in scenarios where the call option valuation requires the use of a binomial lattice model or Monte Carlo simulations, it might be beneficial to measure the fair value of token loan receivables as a whole to avoid unnecessary complexities.

Conclusion:

If all three criteria above are met, the call option requires bifurcation and should be separately accounted for as an embedded derivative, initially and subsequently measured at fair value.

2.2.2.2. Measurement

The valuation approach might be different depending on the specific terms of a call option:

• For a European-style option (both strike price and expiry date fixed at inception) and an American-style option without yield or with a yield rate below the respective risk-free rate, we could use the Black-Scholes-Merton technique, specifically, the closed-form solutions of Reiner & Rubinstein.

• For an American-style option (exercise is allowed at any time before expiry) with a yield that exceeds the risk-free rate, a lattice/binomial model would be more appropriate.

• For an option with path-dependent settlement (e.g., a future TWAP or a present price barrier), a Monte Carlo valuation technique would be more suitable.

Several free tools are available to measure the fair value of this option, including DerivaGem and QuanLib. However, using these tools without performing appropriate testing and authorization may later result in an internal control deficiency unless you address all relevant process risk points appropriately. It is also possible to calculate this value in spreadsheets (see a link to our illustrative spreadsheet at the end of this section). Bloomberg Terminal is also an option.

For illustration, let’s analyze a market-making arrangement with the following details:

Let’s also assume that:

• The annual token inflation is 8%.

• CoinDesk Overnight Rate (CDOR) as of 01/01/2025 is 12.53%

• Historically, the token price volatility was 111.44%, and this is not expected to change in the future.

The key inputs used to calculate the fair value of a strike option include:

Barrier Option type: “Up-and-in call”

• Up: because the barrier is above the current spot.

• In: because the option only knocks in (activates) when the barrier is reached.

• Call: because the right is to buy at the contractual price.

Spot price: $1.15 per token [the fair value as of the inception date]

Dividend yield: 8% [the annual inflation rate of the token based on the anticipated reduction in the price]

Interest rate (Risk-free rate): 12.53% [Normally, a risk-free rate is determined based on the yield rates of U.S. Treasury notes for the respective contractual term of an instrument. We suggest a possible alternative approach that utilizes Coindesk Overnight Rates for USDSC on AAVE, available here; however, this approach may be inappropriate in certain scenarios. Without knowledge of specific facts and circumstances, reporting entities have to consult with their advisors prior to using this approach.]

Volatility: 111.44% [Here, the analysis needs to account for the fact that the MM’s own activity is designed to reduce the spread and thus distorts the observed volatility in a way that violates the market participant premise of ASC 820. As such, reporting entities should attempt to use the implied volatility (when an active market exists for token options) or, otherwise, use historical or comparable token volatility. The best practice is to inform users about the effect of changes in the volatility assumption in a sensitivity disclosure within the footnotes to the financial statements.]

Strike: $1.25 [This is stated in the contract price for the purchase of tokens based on the exercised MM call. This price is often calculated as a Token Weighted Average Price (TWAP) over an agreed-upon period.]

Maturity (in years): 0.2056 [As per our example, from the time when tokens were transferred to MM (on 1/1/2025) until the option expires (on 3/15/2025).]

Rebate: $0.00 [In barrier options, a rebate is a cash amount paid upon either failure to achieve the barrier or termination. It’s non-zero only if the contract explicitly promises some payment when the main option doesn’t deliver its usual payoff.]

Additional adjustments: [The payoff is defined at expiry, but settlement is delayed; therefore, we add an extra discount factor to account for the lag between the call option expiry date (03/15/2025) and the loan settlement date (03/31/2025).]

Barrier level: $2.50 for Call Option With a Barrier and None for Call Option Without a Barrier [A barrier is a pre-set price level of the underlying asset that, if reached, either activates (knock-in) or extinguishes (knock-out) an option.]

Refer to the details on how to measure this call option in our illustrative gsheet.

2.2.2.3. Recognition

The following journal entries would be recorded at inception and subsequently at interim periods:

1. Recognize the token loan receivable:

   DEBIT Token loan receivable

   DEBIT Unrealized loss

   CREDIT Digital assets

   CREDIT Unrealized gain

2. Recognize the embedded derivative liability at fair value:

   DEBIT Token loan receivable - Premium

   CREDIT Embedded derivative liability

3. Remeasure the embedded derivative liability at fair value at interim periods:

   DEBIT Unrealized loss

   DEBIT Embedded derivative liability

   CREDIT Unrealized gain

   CREDIT Embedded derivative liability

4. Amortize token loan premium:

   DEBIT Other expenses

   CREDIT Token loan receivable - Premium

It might also be argued that the embedded derivative liability should be accounted for separately from the loan because the purpose of issuing this call option is to pay for services provided by the market maker. As such, in our opinion, the embedded derivative liability might also be recognized as follows:

1. Recognize the embedded derivative liability at fair value:

   DEBIT Prepaid MM fees

   CREDIT Embedded derivative liability

2. Amortize prepaid MM fees through the contract term:

   DEBIT Selling, general, & administrative expenses

   CREDIT Prepaid MM fees

2.2.2.4. Derecognition

The call option will ultimately be either exercised or will expire. Either of those events concludes the embedded derivative accounting by derecognizing any remaining balance of an embedded derivative and recording the corresponding adjustment to other income/(expense).

Derecognition as a Result of the Exercise

Generally, the debt-modification and extinguishment guidance of FASB ASC Topic 470-50 does not apply to the option exercise because the call option was part of the agreed-upon terms from the loan origination date, and there was no subsequent change. However, amendments to token loan agreements made after the inception date that add or reset the option would be evaluated under the modification guidance.

Upon exercise, the reporting entity will need to record how it:

1. Derecognize the derivative liability related to an exercised option:

   DEBIT Embedded derivative liability

   CREDIT Other income

2. Account for the return of the loan once a stablecoin payment is received as proceeds from the sale of tokens to non-customers:

   DEBIT Stablecoins

   CREDIT Other income

3. Derecognize the cost basis of tokens sold to a non-customer:

   DEBIT Other expenses

   CREDIT Token loan receivable

4. Account for the realized gains/losses on the transaction:

   DEBIT Unrealized gain / Realized loss

   CREDIT Realized gain/Unrealized loss

Derecognition as a Result of the Expiration

1. Expiration of an option will be accounted for using the following journal entry:

   DEBIT Embedded derivative liability

   CREDIT Other income

2.2.2.5. Presentation

Offsetting the call option-related derivative against token loan receivables is not appropriate, as only MM (not TI) has the legal right to exercise the option. Hence, the company would record the token loan receivable as an asset and the call option derivative as a liability.

Changes in the call option fair value have no impact on the interest income because the derivative reflects market risk rather than the time value of money.

2.2.2.6. Other Considerations

Because token loan receivables are not financial assets, ASC 860 “Transfers and servicing” would technically not be applicable, which creates a significant opportunity for abusive/creative accounting. It will allow reporting entities to recognize income in situations where they would be precluded from doing so when operating with financial assets. At the same time, we would also be cautious of applying ASC 860 by analogy. In-depth analysis is required based on specific facts and circumstances to ensure the appropriate accounting treatment.

2.2.3. Allowance for Credit Losses

ASC 326 includes two practical expedients that permit consideration of the fair value of the collateral at the reporting date when determining the allowance for credit losses. These practical expedients are available in the following two scenarios:

• Collateral dependence [ASC 326-20-35-5] for a financial asset where the borrower is experiencing financial difficulty and (based on the entity’s assessment as of the reporting date) the repayment is expected substantially through the operation or sale of the collateral.

• Collateral maintenance [ASC 326-20-35-6] when the borrower is contractually required to continuously adjust the amount of collateral securing the financial asset as a result of changes in the fair value of collateral.

In market-making arrangements, token receivables are expected to be repaid substantially through the operation or sale of tokens. Further, the fair value of tokens changes is automatically reflected in the change of the fair value of the token receivables. If the receivable is measured at fair value through earnings under FASB ASC Topic 825-10, no credit loss allowance is required to be assessed for this instrument. Otherwise, when expected credit losses are estimated under FASB ASC Topic 326 and there is a legally enforceable right to liquid collateral with maintenance/margining provisions, the expected credit loss may be immaterial.

2.3. Liquidity Deprovisioning

Under both models, the repayment of tokens is accounted for by crediting the token loan receivable and debiting the account used for tracking held in the issuer-controlled wallet tokens:

DEBIT Digital Assets

CREDIT Token Loan Receivable

However, when the call option (issued under the loan/call option model) is exercised, the settlement of token loan receivables will typically be performed using stablecoins in the amount calculated using the number of tokens loaned and specified in the contract price (usually, using the Time Weighted Average Price or TWAP at the loan inception). Correspondingly, the repayment made using stablecoins is accounted for by crediting the token loan receivable and debiting the stablecoin account:

DEBIT Stablecoins

CREDIT Token Loan Receivable

3. Disclosures

Given the complexity and lack of specific guidance for market-making arrangements, reporting entities should include extensive quantitative and qualitative disclosures to enhance the user’s understanding of how market-making affects the entity’s financial position, results of operations, and cash flows. These disclosures should directly address the nature of market-making activities, terms of existing arrangements with market makers, regulatory compliance considerations, accounting policies, and other relevant factors discussed in this article.

Illustrative footnote disclosures are provided here:

Conclusion

Accounting for market-making arrangements in the Web3 and digital asset ecosystem requires advanced expertise in both the crypto landscape and relevant accounting standards. Each model presents distinct accounting and operational considerations.

As the market continues to evolve, it remains essential for reporting entities engaging market makers to monitor regulatory developments and proactively refine their internal processes. To support transparency, mitigate risk, and pursue new opportunities, organizations must conduct thorough reviews and analyses of their arrangements with market makers.

We list common scenarios of performance obligations in software revenue arrangements relevant for the majority of businesses selling software or related services and identify the appropriate treatment of each scenario under US GAAP.

Licensed Software Arrangements

The term “Licensed software” refers to the licensing of software by granting the customer the right to use the software. Software is the intellectual property (IP) that has significant standalone functionality. The customer in this arrangement would acquire the right to use the IP because it has standalone functionality, and the customer can use the IP as it exists at a specific point in time.

Outside of one exception that we will address below, revenue from licensed software is recognized at the point in time of the license term's inception date. It is regardless of the license term's duration and whether it is finite or perpetual. However, the license term remains relevant, as its duration will affect the standalone selling price estimate, and consequently, it will impact the allocation of the transaction price.

Now, as we mentioned earlier, there is one exception to this rule. This exception addresses situations in which a software license grants the right to access the underlying intellectual property rather than to use it. Both of the following conditions should have been satisfied for this exception to be applicable:

“a) The functionality of the intellectual property to which the customer has rights is expected to substantively change during the license period as a result of activities of the entity that do not transfer a promised good or service to the customer (see paragraphs 606-10-25-16 through 25-18). Additional promised goods or services (for example, intellectual property upgrade rights or rights to use or access additional intellectual property) are not considered in assessing this criterion.

b) The customer is contractually or practically required to use the updated intellectual property resulting from criterion (a).”

[FASB ASC 606-10-55-62]

For both conditions to be satisfied, the software license and its subsequent updates should be viewed as a single combined performance obligation (PO), rather than distinct POs. As a result, the revenue recognition from a combined performance obligation will usually follow the over-time recognition pattern with a time-based measure.

Subscribe now

Software as a Service Arrangements (SaaS)

The term “SaaS” may refer to either:

1. Granting the customer the right to access the functional IP (software).

2. Specified cloud-based services.

This assessment is highly judgmental and may be based on the following non-exhaustive lists, where no single factor has a greater weight:

a) “Right to access” factors:

• Right of access/use of the platform that has either no limit or a non-substantive limit.

• Service is not sold separately on a pay-as-you-go basis.

• The vendor continues to provide platform access support services throughout the contract term.

• The customer consumes benefits from the platform over a contract term, rather than specific usage or outputs, such as processing transactions or data.

When SaaS is a promise to provide access to the platform during a specified time period, the revenue progress measure is a time-based measure.

b) “Specified services” factors:

• A specified amount of usage/transactions is fixed, and any incremental consumption must be purchased separately once the initial allowance is exhausted.

• The platform allows rolling over unused pre-purchased consumption credits.

• Service is being sold separately on a pay-as-you-go basis.

• Access to the platform by itself does not significantly benefit customers unless it is utilized or applied, such as through the consumption of its outputs, including data or processed transactions.

When SaaS is a promise to provide specified services, the measure of progress is based on the services provided, i.e., the revenue is recognized based on the amount of service consumed by customers or via a usage-based measure.

Hybrid arrangements

Both SaaS and Licensed software may be present in the same “hybrid” arrangement. Here, the accounting will depend on the assessment of whether licensed software and SaaS components are considered distinct. This assessment requires significant judgment and an understanding of the functionality of each component and the service, as well as how they interact with each other.

For example:

• If the customer is required to use the licensed software and SaaS service together to benefit from the purchase, both elements are combined into a single performance obligation in accordance with ASC 606-10-55-56.

• On the other hand, licensed software with significant standalone functionality is typically distinct from SaaS services because the customer can benefit from the license even without the service.

The following considerations support the conclusion that both elements are to be combined into a single performance obligation:

• Significant degree of interaction on a regular basis with a “two-way” dependency between the on-premises software and SaaS.

• The interaction between licensed software and SaaS enables customers to derive the intended benefits.

• Together, licensed software and SaaS provide new functionality or significantly modify existing functionality due to the transformative rather than additive relationships.

• The two elements together provide new or different functionality; in other words, the SaaS functionality is transformative rather than additive.

• Similar benefits cannot be practically obtained from SaaS provided by alternative vendors.

• Marketing materials communicate the value of the product offering on a combined, rather than a standalone, basis.

Revenue allocated to a performance obligation combining a license and cloud-based services is generally recognized over time using a time-based measure.

Hosting arrangements

A hosting arrangement exists where a customer does not obtain the licensed software in its possession but rather remotely accesses the software hosted on third-party hardware. As per ASC 985-20, Costs of Software to be Sold, Leased, or Marketed, a hosting arrangement includes a distinct software license only if:

1. It is feasible for the customer to run the software on its own or by contracting with an unrelated third party, and

2. There is a contractual right that allows the customer, at any time during the hosting period, to take possession of the software without significant penalty.

The relevant considerations related to the above two criteria incorporate:

• The significance of incremental infrastructure costs required in order for a customer to host the software locally.

• The ability to use software separately without diminishing its utility.

• The ability to absorb penalties for terminating the hosting arrangement (including forfeitures of nonrefundable upfront payments for services).

If the hosting arrangement meets both criteria, both licensed software and SaaS service elements are considered distinct, and revenue is recognized for:

• Initial license (distinct): at a point in time.

• Future upgrades (distinct): at a point in time.

• Initial license combined with upgrades: time-based measure.

• Hosting service (distinct): using a service usage measure.

Otherwise, the two elements of the hosting arrangements would be treated as a hosting service contract. Such an arrangement would typically be accounted for based on a series of guidance as per ASC 606-10-25-14(b).

Arrangements where the licensed software is not distinct from other services and products in the contract (including SaaS)

In arrangements where software licenses are not distinct from other products or services, it is possible that software will not be separately accounted for. Software will be combined with different promises, and revenue will be recognized based on the combined performance obligation. Specifically, ASC 606-10-55-56 requires this approach when the software is:

1. A license integral for the functionality of a tangible good.

2. A license that the customer can benefit from only when such a license is combined with a related service (for example, an online service enabling the customer access to content by granting a license).

For example, an arrangement to deliver software and customer support for a period of twenty-four months. The software vendor must determine whether the software license and post-purchase customer support are distinct or should be accounted for as a single performance obligation. As per ASC 606-10-55-46(b), a license is not distinct if it can only be used in conjunction with a related service (e.g., a license that solely enables a customer to access an online service).

For licenses that are not distinct and are bundled with other goods or services, reporting entities will need to apply judgment to assess the nature of the combined item and determine whether the combined performance obligation is satisfied at a point in time or over time.

Conclusion

Software revenue recognition can be complex due to the numerous models that may apply, depending on subtle variations in contract terms and conditions. The insights shared in this article help bring clarity to this question. If you have any additional questions related to the assessment of your contracts under ASC 606, reach out.

Background

In 2025, the reporting entity incurred $300,000 in legal fees in connection with the agreement to raise $5 million by issuing 50 million shares of common stock. How should these amounts be presented in the financial statements?

Relevant Guidance

The accounting for costs associated with raising capital has relatively limited guidance. FASB ASC 340-10-S99-1 contains the requirement to reduce proceeds from the issuance of instruments classified as equity by the amount of associated direct costs. To qualify for capitalization, costs should be directly associated with the raise.

At the same time, this guidance explicitly excludes the following costs from its scope:

• costs of aborted offerings,

• management salaries, and

• general and administrative (G&A).

Further, direct costs related to obtaining the equity financing would also be expensed in any of the situations listed below:

1. An offering that has been postponed for an extended period of time.

2. An offering that has been cancelled.

3. Capital transaction with no proceeds received by the entity:

   1. An IPO in which only pre-existing shareholders sell stock.

   2. Secondary sales.

Subscribe now

As a side note, we would also always expense any direct costs of fundraising via the sale of tokens. This assumes that tokens do not represent debt or equity instruments for accounting purposes:

• If tokens represent an equity instrument, the reporting entity would follow the respective guidance for direct costs of equity financing, as discussed throughout this post.

• If tokens represent a debt instrument, we would follow the respective guidance for debt issuance costs, which we do not cover today.

Scenarios in which Direct Costs are Capitalized

As discussed above, to qualify for capitalization, costs must be directly associated with the fundraising and should not fall under any of the exceptions identified above. The presentation of capitalized direct costs of fundraising will differ depending on whether the common stock is issued with a par value or without one.

Common Stock With Par Value

When common stock has a par value, this value is presented on the balance sheet under the item “Common Stock”, with any premium (a positive difference between the proceeds and the nominal value) presented as "Additional Paid in Capital". Use a separate account named "Additional Paid In-Capital - Direct transaction costs of common stock issuance"1 to record the total premium received on the sale of common stock.

If legal costs exceed the premium, record a reminder to the “Common Stock” item on the balance sheet, using a separate account titled “Common Stock - Direct Transaction Costs of Common Stock Issuance.”

If legal costs exceed the proceeds from fundraising and the total balance of the "Additional Paid in Capital" and “Common Stock” prior to capitalization of legal expenses, record a reminder to the “Retained Earnings” item on the balance sheet, using a separate account titled “Retained Earnings - Direct Transaction Costs of Common Stock Issuance.”

Common Stock With No Par Value

In situations when stocks have no par value2 (e.g., Canadian corporations), all proceeds would be recorded to the "Common Stock" account. Accordingly, when common stock has no par value, the legal costs associated with raising capital are deducted from the proceeds. These costs are recorded directly to the "Common Stock” account.

Below, we present different outcomes for the four scenarios where the only difference is the par value of one common share issued:

Based on this data, we can calculate the total par value and premium received under each scenario as follows:

Results are shown below:

After posting required journal entries as discussed above, our general ledger (G/L) accounts in the trial balance sheet should have the following balances:

For financial reporting purposes, general ledger (G/L) accounts are aggregated into individual line items within the financial statements.

Conclusion

As demonstrated above, reporting entities should carefully consider the par value amount of stock issued when accounting for the direct cost of fundraising and subsequently preparing the financial statements, as the presentation of such costs varies significantly depending on the par value of the stock issued.