Initial Coin Offering

Initial Coin Offering

An Initial Coin Offering (‘ICO’) is a form of fundraising that harnesses the power of cryptographic assets and blockchain-based trading. Similar to a crowdfunding campaign, an ICO allocates (issues or promises to issue) digital token(s) instead of shares to the parties that provided contributions for the development of the digital token. These ICO tokens typically do not represent an ownership interest in the entity, but they often provide access to a platform (if and when developed) and can often be traded on a crypto exchange. The population of ICO tokens in an ICO is generally set at a fixed amount.

It should be noted that ICOs might be subject to local securities law, and significant regulatory considerations might apply.

Each ICO is bespoke and will have unique terms and conditions. It is critical for issuers to review the whitepaper (A whitepaper is a concept paper authored by the developers of a platform, to set out an idea and overall value proposition to prospective investors. The whitepaper commonly outlines the development roadmap and key milestones that the development team expects to meet) or underlying documents accompanying the ICO token issuance, and to understand what exactly is being offered to investors/subscribers. In situations where rights and obligations arising from a whitepaper or their legal enforceability are unclear, legal advice might be needed, to determine the relevant terms.

ICOs might be considered to be securities by a securities regulator, but it is important to note that there is no uniform global view. As a result, issuers should monitor regulatory developments closely and consider the impact that any changes might have on financial reporting.

Accounting for token pre-sale agreements

Entities looking to raise funds via an ICO sometimes make use of a ‘Simple Agreement for Future Tokens’ (‘SAFT’) to attract seed investors and lock in funding from interested parties in private sales prior to a public sale. A SAFT is an early-stage investment, pre-ICO, where the investor provides upfront funding to the issuer in exchange for a promise to receive a variable number of tokens on a successful ICO.

The number of tokens to be received by the SAFT investor usually depends on the ICO token price on issuance. As an incentive for investing in the pre-ICO entity, the SAFT issuer will typically settle the SAFT using an ICO token price that is discounted by a predefined amount (for example, a 10% discount to the ICO token price at issuance). Thus, on a successful ICO, the SAFT investor will receive a number of tokens equal to the value of what was originally invested, plus a return equal to the specified discount on the ICO token.

Terms of a SAFT can vary, impacting the determination of the accounting treatment. Factors to consider include (but are not limited to) the characteristics/features that the tokens will have, and the rights to which the future holders will be entitled.

A case – SAFT

One common form of SAFT is a SAFT on utility tokens that entitles the investor to a discounted price for tokens compared to other investors at the time of an ICO. Typically, the SAFT terminates if the ICO does not happen on or by a stated date, at which time the entity is required to return to the investor the amount originally invested (or a portion thereof). The success of an ICO is not within the control of the entity – for example, the ICO is abandoned if the minimum fundraising goal (sometimes referred to as a ‘soft cap’) is not achieved. A SAFT holder does not have the right to redeem its SAFT prior to the stated date.

If the utility tokens underlying the SAFT clearly entitle the holder to future goods and services, those tokens would not be considered a financial instrument. It follows that, from the perspective of the issuer, a SAFT to deliver a utility token might be viewed as not within the scope of IFRS 9, because it is usually not a contract “to buy or sell a non-financial item that can be settled net in cash or another financial instrument, or by exchanging financial instruments, as if the contracts were financial instruments”. [IFRS 9.2.4]. In such a case, the SAFT might be viewed as a customer’s prepayment for future goods and services under IFRS 15, ‘Revenue from Contracts with Customers’.

However, on the basis that the occurrence of a successful ICO is beyond the control of the entity, and the characteristics of the tokens to be issued might be unclear, some might view the SAFT as containing a financial obligation, because it represents a contractual obligation to deliver cash if the ICO does not occur by the stated date. In such a case, the SAFT might be viewed as a financial liability of the issuer in accordance with IAS 32 at initial recognition. There might also be other embedded features which require further assessment, such as embedded derivatives based on the specific terms of the arrangement.

Something else -   Hold to collect - How 2 best account it in IFRS 9 classification of financial assets

Off course – Facts and circumstances will need to be carefully evaluated in determining which view appropriately reflects the overall substance and economics from the issuer’s perspective.

Accounting for ICOs by the issuer

When an ICO is undertaken, the issuing entity receives consideration. The form of the consideration varies (for example, cash or another cryptographic asset) and, for accounting purposes, it is key to understand the economics and characteristics of the transaction.

It is possible that an ICO could create a joint arrangement requiring further analysis based on IFRS 11, ‘Joint Arrangements’. The fact that the subscribers provide the majority of the funding might suggest that the arrangement is a collaboration between the ICO entity and the subscriber. However, the subscribers are typically passive, which suggests that the arrangement might not provide the parties with joint control. Some issuers might grant, to subscribers, veto rights over the future direction of the project; these are typically protective in nature and, in most cases, they will not create joint control.

Where consideration for the ICO is not in the form of cash but another cryptographic asset, the transaction might be an exchange of similar goods or services. An exchange of similar goods might mean that no accounting is needed. However, it seems unlikely that an ICO will be an exchange of ‘similar goods or services’, because no two cryptographic assets are generally alike.

Assuming that there is an exchange transaction and that the arrangement does not create joint control, the consideration received by the ICO entity is recorded as the debit side of the journal entry. Depending on the form of the consideration, this might involve the thought process explained in Cryptocurrencies.

However, the key challenge for issuing entities is determining the accounting for the ICO token issued (that is, the credit side of the journal entry). This will depend on the nature of the ICO token issued, as well as the guidance of the applicable accounting standard.

The following figure provides a possible analysis framework of accounting models to consider when determining the nature of, and accounting for, the issued ICO token. Consideration of the contract terms is needed, to understand the obligations of the issuer:

Initial Coin Offering

IFRS 9 – Financial liability

An issuer of an ICO token should assess whether a token meets the definition of a financial liability. Specifically, an entity would consider the definition in IAS 32, which states that a financial liability is:

  • a contractual obligation:
    • to deliver cash or another financial asset to another entity; or
    • to exchange financial assets or financial liabilities with another entity under conditions that are potentially unfavourable to the entity; or
  • a certain contract that will or might be settled in the entity’s own equity instruments, such as those that violate the principle stated in IAS 32.11 (commonly known as the ‘fixed-for-fixed’ principle).

If the ICO token is a financial liability, the accounting would follow the applicable guidance in IFRS 9.

Many ICO tokens will not meet the definition of a financial liability, but there are situations where the terms and conditions might provide for a refund of proceeds up to the point of achieving a particular milestone. There might be situations in which the contract creates a financial liability, at least up to the point at which the refund clause falls away.

IAS 32 – Equity instrument

An equity instrument is any contract that evidences a residual interest in the assets of an entity after deducting all of its liabilities. [IAS 32.11]. Typically, ICO tokens do not provide the holders with such a residual interest; for example, they do not give the holders rights to residual profits, dividends, or entitlement to proceeds on winding up or liquidation.

These ICO tokens might therefore lack the characteristics of an equity instrument. Careful consideration is needed to assess whether the rights to the cash flows only relate to a specific project or whether, in substance, they provide rights to residual cash flows of the ICO entity.

IFRS 15 – Revenue transaction/prepayment for future goods and services

The issuing entity should consider whether the ICO token issued is, in substance, a contract with a customer that should be accounted for under IFRS 15.

IFRS 15 would apply if:

  1. the recipient of the ICO token is a customer,
  2. there is a ‘contract’ for accounting purposes, and
  3. the performance obligations associated with the ICO token are not within the scope of other standards.

IFRS 15 defines a customer as “a party that has contracted with an entity to obtain goods or services that are an output of the entity’s ordinary activities in exchange for consideration”.

To determine whether a contract with a customer exists, an entity should consider whether the whitepaper, purchase agreement and/or other accompanying documents create ‘enforceable rights or obligations’. [IFRS 15 Definitions]. To be a contract with a customer for the purposes of IFRS 15, such rights should be legally enforceable. This assessment might be challenging where the documentation provided by the issuer is not well defined. Entities should further evaluate all of the criteria in IFRS 15.9, to determine if a contract with a customer exists.

Something else -   Contingent liability

Whitepapers – Legally enforceable rights?

Whitepapers are not the same as a standard legal contract or other offering documents (such as a prospectus or offering memorandum). Entities should carefully examine the whitepaper or similar document, to make sure that there are, in fact, legally enforceable rights. Clauses that disclaim any legal obligation by the issuer require further investigation. In some situations, additional legal advice might be needed.

In many circumstances, issuers might use the consideration received in the ICO to develop a software platform. Hosting and maintaining the specific platform is often an integral part of the ICO’s future business model. The token could provide the holder with access to the platform, which might be operated as part of the entity’s ordinary activities.

This might result in the holders meeting the definition of ‘customers’, from the perspective of the ICO entity; accordingly, the proceeds from the ICO could be revenue of the issuing entity, which will likely be initially deferred.

Determining the performance obligations, how they are satisfied and the period over which to recognise revenue will be judgemental and will depend on the specific facts and circumstances of the ICO offering.

Consider other relevant guidance

Where none of the above considerations appear to be relevant, the hierarchy in IAS 8 should be considered in determining the appropriate accounting treatment. The general assessment is that it is unlikely that issuers will receive consideration without taking on an obligation to the subscribers. Even if the arrangement does not give rise to a financial instrument or a promise to deliver goods or services to a customer, there is likely to be a legal or constructive obligation to the subscriber. This might result in the issuer recognising a provision in accordance with IAS 37.

Accounting for a purchase of goods or services by the ICO entity in exchange for ICO tokens issued

General considerations

Some issuers of ICO tokens might choose to keep some tokens generated through the ICO, to use as a means of payment for goods or services. Examples of the use of such ICO tokens include obtaining services in developing or operating the entity’s platform, or to remunerate/incentivise employees. This is explored further in the followingInitial Coin Offering sections.

When an ICO entity allocates a specified number of ICO tokens for the purpose of its own use, it should consider the accounting for the generation of the ICO tokens itself.

The generation of ICO tokens for own use does not generate proceeds for the ICO entity. The act of generating ICO tokens is not, in itself, an exchange transaction.

Generating ICO tokens is similar to a retail store printing vouchers for discounts on future purchases at the store and not distributing them to customers. Therefore, it seems appropriate that such an event would not be considered for accounting purposes. This situation changes once the vouchers are provided to third parties in exchange for consideration – or, in accounting terms, once an exchange transaction takes place.

An ICO entity would not usually account for the generation of tokens until an exchange transaction has occurred.

Own cryptographic assets exchanged for third party services

Sometimes, ICO tokens are provided to third parties for services, such as developing a platform. The observations summarised in this section cover situations in which the receiving party is determined to be a third party (and not an employee, as defined in IAS 19, ‘Employee Benefits’).

In order to determine the appropriate accounting treatment for an exchange transaction that takes place between an ICO entity and a third party, it is important to obtain a detailed understanding of the economic substance of the exchange.

Generally, the accounting will follow:

  • the substance of what the ICO entity receives in return for cryptographic assets (debit side of the journal entry); and
  • the characteristics of ICO tokens generated and delivered by the entity.

When determining the debit side of the journal entry, an entity would consider the nature of the goods or services received and whether there are costs that can be capitalised as an asset, or if the costs are to be recognised as an expense. For example, if the payment is to develop software, can the costs be capitalised as part of the intangible, based on the applicable IFRS guidance, or should they be expensed (for example, research and development guidance under IAS 38)?

The credit side of the entry is determined by the obligations that the entity incurred as a result of issuing the ICO tokens. This assessment determines the applicable standard, based on the promises associated with the ICO tokens. The thought process of the assessment will be aligned with the considerations described in Cryptocurrencies..

Something else -   Hold to collect and sell - How 2 best account it in IFRS 9 classification of financial assets

For example, where the ICO tokens provide an entitlement promise to deliver future goods or services to a customer (such as a discount on future services provided by the ICO entity), the credit side of the journal entry should be determined based on IFRS 15. In this case, the revenue from providing the ICO tokens should be measured at the fair value of the goods and services received by the ICO entity.

Own ICO tokens exchanged for employee services

Some ICO entities might reward their employees in the form of a specific number of tokens generated through the ICO. IAS 19 ‘Employee benefits‘ or IFRS 2, ‘Share-based Payment’, might need to be considered.

When assessing the accounting treatment of such arrangements, an entity considers the characteristics of the ICO tokens generated.

Unless the ICO tokens meet the definition of an equity instrument of the ICO entity (that is, a contract that has a residual interest in the assets of the ICO entity after deducting all of its liabilities), the arrangements would not meet the definition of a share-based payment arrangement under IFRS 2. Instead, they would fall within the scope of IAS 19 as a non-cash employee benefit.

IAS 19 will then determine the recognition, as well as the measurement, of the employee benefit, as shown in the following example:

A case – Fringe benefits

An ICO entity rewards named employees in the form of a specific number of utility tokens generated (and currently held) by the ICO entity. Based on the nature and characteristics of the utility tokens, the entity concludes that they are, in substance, a contract with a customer that should be accounted for under IFRS 15, with the employee being the customer in this situation.

The reward is ‘paid’ shortly after the end of the financial year in which the ICO was successfully executed to the employees who:

  1. contribute to the success of the ICO; and
  2. stay in their jobs until the end of the financial year in which the ICO was successfully executed.


The ICO entity determines that the substance of the arrangement is an exchange of employee services for goods and services to be delivered by the entity. This is accounted for as a short-term employee benefit [IAS 19.11, IAS 19.19–23] and non-cash consideration for goods and services. [IFRS 15.66–69].

The arrangement includes a condition that the employees should remain in their jobs at the ICO issuer during the vesting period. The ICO entity should recognise a liability and short-term employee benefit expense over the vesting period. The liability will be reclassified as deferred revenue when the employees obtain the right to access the utility tokens on their digital accounts.

This treatment is also consistent with the definition of a contract liability in IFRS 15, which states that a contract liability arises when the entity has received the consideration. In this case, this is when the employee services have been provided.


The ICO entity recognises the undiscounted amount that it expects to pay in exchange for the services provided by the employees as a liability and an expense. [IAS 19.11]. The ICO entity could measure the amount that it expects to pay by using the fair value of the utility tokens to be delivered to the employees, or by using the estimated cost of the goods or services that it expects to deliver in the future.

Journal entries:

As service provided over vesting period

When utility tokens issued from ICO

Dr Employee costs

Dr Short-term employee benefit liability

Cr Short-term employee benefit liability

Cr Deferred revenue

Off course – The circumstances of each transaction will need to be carefully evaluated in determining which view appropriately reflects the overall substance and economics, from the issuer’s perspective especially, regarding the measurement of the benefits provided.

Annualreporting provides financial reporting narratives using IFRS keywords and terminology for free to students and others interested in financial reporting. The information provided on this website is for general information and educational purposes only and should not be used as a substitute for professional advice. Use at your own risk. Annualreporting is an independent website and it is not affiliated with, endorsed by, or in any other way associated with the IFRS Foundation. For official information concerning IFRS Standards, visit or the local representative in your jurisdiction.

Something else -   Sale of hardware and installation services

Initial Coin Offering

Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering

Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering Initial Coin Offering

Leave a comment