Many blockchain projects raise funds to develop their technology and the network through:

  • a private token sale through issuing a simple agreement for future tokens (SAFT); and/or
  • a public token sale through an initial coin offering (ICO).

In the many cases that we work on, the tokens are typically utility and/or governance tokens.  A utility token may provide access to the network's products or services, whereas a governance token will allow the holder to vote on how the network operates.

A SAFT typically provides an obligation on the company to provide tokens where there is a token generation event (TGE).  Absent a TGE, there is no obligation on the company to provide tokens or compensation in place of tokens.

Typically, SAFTs are issued to some or all of the following categories of recipients:

  • Token investors
  • Founders
  • Shareholders
  • Advisers
  • Employees.

The tax treatment of tokens acquired under a SAFT will differ depending on which camp the recipient falls within.  Some will fall within more than one category.  The facts will dictate which tax treatment to apply and establishing a value for the SAFT is critical in assessing the amount of tax that will be paid.

Independent third-party investors acquiring the tokens under the SAFT typically have a very clear tax position because they have a base cost (i.e., the price they paid). It doesn't matter that subsequently, at the time they receive their tokens, there is an ICO where the tokens trade at a higher price.  We do not comment on token investors further in this article.

In an ideal world, all of the remaining categories of recipient would enter into a SAFT under which they pay market value for their tokens (at the time of entering into the SAFT) and that market value would be nil or low due to a number of hurdles to a TGE taking place. These might include:

  • Technology not yet being fully developed
  • No revenue / no confirmed commercial traction
  • Volatile market
  • Competitors
  • Regulatory risk.

However, the real world is not ideal. In practice:

  • Founders will be the last to receive a SAFT as they are typically focused on developing the technology, raising funds, preparing for a token sale and their attention is turned to their SAFT merely days or weeks before an ICO.  The position as to whether they received the tokens by virtue of their shareholding, or their employment duties is unclear and there is often insufficient tangible evidence to point either way. Although it shouldn't, HMRC has the benefit of hindsight and the founders could then be taxable on the value of the tokens at the TGE, even if the tokens are subject to a lock-up (i.e. where the holder can't sell the tokens until the lock-up has ended).
  • Advisers will agree to provide services in return for tokens. These tokens will be treated as consultancy fees and subject to UK income tax (or where the service is provided through a company to UK corporation tax), but absent any evidence to show the value of those services, the adviser could be taxed on the value of the tokens at the time of receipt (i.e. the price they are trading at after ICO).
  • Employees will be subject to income tax and the company will need to deduct PAYE including employers NI at the time of a taxable event.
  • Shareholders will sometimes subscribe for equity and their subscription agreement will include the right to receive tokens / entering into a SAFT, but no price for the tokens is established. This could lead to the receipt of tokens at a TGE being treated as a dividend, subject to income tax at 38.1% or potentially exempt where the shareholder is a UK company.

In all of the above scenarios, the recipients may be subject to a dry income or corporation tax charge. Potentially forcing them to sell the tokens to fund the tax.  In some cases, the tokens will economically belong to the recipient at the TGE, but they cannot sell them until the lock-up has ceased, only further frustrating the dry tax charge impact.

Our recommendations are:

  • Founders/shareholders: most blockchain companies will know early on whether there is scope to incorporate a utility token into their product/service offering and, if so, that they will aim to undertake an ICO. Founders should prioritise their own SAFTs by:
    • undertaking a valuation of the tokens as early as possible (and ideally pre issue of SAFTs to third parties); and
    • drafting the SAFT to include an acquisition price designed to demonstrate that the market value (at the time of entering into the SAFT) is being paid.
  • Advisers:  should provide their annual / monthly / daily consultancy fee rate and negotiate a discount in return for a SAFT. This rate and discount should be documented by email and in the recitals to the SAFT.  The adviser should report the pre-discount amount as income on his/its tax return. A dry tax charge should only arise in respect of the discounted amount (i.e. the value attributable to the SAFT) and not the value of the tokens on receipt of a TGE.
  • Employees:  early employees should enter into a SAFT with an acquisition price which seeks to establish the market value for the tokens at that time.  For ongoing employee incentivisation, consideration should be given to providing the tokens to employees under option arrangements; the employee only exercises the option when he is ready to sell the token (and can, therefore, fund the tax charge).
  • Document all hurdles to a TGE. Review these hurdles at regular board meetings documenting any changes.
  • Obtain an independent market valuation of the token. Our valuations team regularly undertake valuations of digital assets (as opposed to valuing the shares in the company). This can be invaluable in addressing any HMRC inquiries which will take place at a time when (hopefully) the tokens have proved to be valuable because all of the hurdles to a successful TGE have been overcome.

Originally published June 2021.

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.